indigophox commented on PR #34817: URL: https://github.com/apache/arrow/pull/34817#issuecomment-1904780493
> The problem with say, DoAction, is that it's a streaming response, so in theory the RPC handler can start returning results, and then you can't call SendingHeaders anymore (it needs to be before you send any headers). The one saving grace is that our DoAction doesn't let you directly send results, instead you return an iterator. So then we can implement the potentially very confusing API where the body of DoAction() itself can affect what SendingHeaders sees, but NOT the iterator's body. Probably this is OK in general because most people will return a dummy iterator (and you shouldn't expect to affect headers after the iterator has started running), but it is odd. Ok, figured it was the streaming responses that were the issue. I take it this is probably a reasonably limited scope of work, i.e. at the stream handling termination points? Not 100% clear about there being an Iterator for the results, from the interfaces I'm just aware of there being a Result posted to the RPC result stream for DoAction. It's definitely possible to ensure that the state for SendingHeaders is finalized prior to posting/returning the RPC response to the DoAction result stream. Hopefully we can figure something out to keep the merge unblocked even though this is blocking most of the integration testing on the C++ side—up to you if that means forgoing the C++ tests (the tests work as far as possible so the C++ protocol handling looks good) or if we can (seems likely?) move ahead with the workaround as you discussed above? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
