Inproc transport assumptions not consistent with C++ callback API or some wrapped languages #23398
Description
What version of gRPC and what language are you using?
head, C++
What operating system (Linux, Windows,...) and version?
N/A
What runtime / compiler are you using (e.g. python version or version of gcc)
N/A
What did you do?
Determined that the assumptions in the inproc transport don't match the C++ callback API (or Python). In particular, the transport assumes that if the client has already issued a recv_trailing_md op that it will not issue any further recv_message ops. This was true for the C++ sync and async APIs but not for the callback API. It is also not true for Python and possibly other languages. The consequence of this is that some server-side send message operations might be canceled. In practice, #23380 fixes the cases of this that have actually been seen so far, but we need to further investigate if any other cases could trigger this assumption.
What did you expect to see?
Transport works with all APIs.
What did you see instead?
Already saw some internal failures on this issue, but may need further tests for completion.