microsoft
Add mechanism to access JsonRpcRequest instance from service implementation
It would be useful to be able to access the JsonRpcRequest (or in my particular case the RequestId) from service implementations so that I can do out-of-band association between client and server requests. Specifically, I'm trying to post-facto recreate a session after it's been terminated with information stored on both parties. To avoid async and threading related race conditions I think it would need to be provided as a special argument to the handler function, but I don't know what the performance implications of adding this would be or the implementation approach.
This strikes me as a code smell, to mix the underlying RPC protocol into the application layer like that. The last time someone asked for this (which wasn't that long ago), it turned out they were trying to address a need that was better addressed another way, and we were able to deliver that. I don't remember the details though.
If you implement your own handler or formatter, you'll have access to this JsonRpcRequest object. If you really need the ID you could potentially log from there yourself. I don't know what you mean by "recreating a session after it's been terminated" but at first blush that sounds ... unsupported.
Sorry for the delay; yes, I'm indeed doing something fairly cursed. What I'm doing is serializing the in-progress server and client state (that is, I save the server-side handlers that the client is waiting on along with the handlers on the client side) to a file, then loading it back again and trying to resume the communication in situ. I currently do this by embedding an id into each message at the application level and to restore the shared channel state the client re-sends all of the pending messages after deserializing its state with a resume marker so that the server can pick up the right bit of serialized internal state.
It's somewhat annoying to have to do this all at the application layer because I have to make and track the IDs alongside those that are already being used in the underlying JSON-RPC communication, which is why I ask.
I already am implementing my own handler for a custom communication channel, but I'm not enormously happy with capturing the last message's ID statefully because there's a lot of potential concurrency footguns I'm worried about there. My system has enough footguns as it is, honestly. I would prefer something that passed the request in because then there's an unambiguous map between response and handler.