With all the changes to the protocol, interfaces, and implementations, the L2 implementations are automatically generating a response message and completing the future with commstatus =DEADLINE_EXCEEDED so the question is, do the dispatchers really need to also determine that a message has timed out and send a response? forcing infrastructure to send these messages adds extra complexity to the streamers and can result in multiple response messages to be sent back to the client.
_Any objections if we remove the responsibility of the dispatchers to generate DEADLINE_EXCEEDED timeout responses in and ensure that RpcClient interface takes care of this (on the client side)?
Actually, I thought about this more and we still need this logic as the auto-reply on the client side is at L2 and we need an end-2-end L1 solution so I'll close this issue
With all the changes to the protocol, interfaces, and implementations, the L2 implementations are automatically generating a response message and completing the future with
commstatus =DEADLINE_EXCEEDED
so the question is, do the dispatchers really need to also determine that a message has timed out and send a response? forcing infrastructure to send these messages adds extra complexity to the streamers and can result in multiple response messages to be sent back to the client._Any objections if we remove the responsibility of the dispatchers to generate
DEADLINE_EXCEEDED
timeout responses in and ensure that RpcClient interface takes care of this (on the client side)?