Test/caller disconnect callee crash - #2153
Conversation
When a caller disconnects while an RPC is in-flight, the router must clean up invocation tracking regardless of whether the callee supports call canceling. Previously, the cleanup was skipped if the callee didn't support call_canceling, leaving stale data structures that caused errors when the callee tried to return a result. The fix: - Always clean up invocation tracking (timeout, data structures) - Only send INTERRUPT message if callee supports call_canceling - Log appropriately in both cases Fixes: crossbario#2133
|
all tests pass now see here |
|
@oberstet I hope I followed your required procedure here. I motivated the issue more clearly in the initial PR comment above. The comments in the new test case give some additional details about the nature of the test and why the fix is a fix. |
|
fantastic! this is a showcase example for the workflow! it's perfect - both for me reviewing, as well as (IMO) for users. thanks also in particular for the detailed comments on the new test ah, and the remaining failed code quality check was completely unrelated to this PR. merging. |
|
love it. thanks so much for the fix! and for taking so much care following the workflow. fwiw, now (together with fixed typo wrt check-typing), workflows are 100% green & happy:
the
|
|
what is still missing here is: |
When a caller disconnects during an in-flight RPC, invocation cleanup was skipped if the callee did not support call_canceling (due to an early continue). This left stale entries in _invocations and _callee_to_invocations, causing errors when the callee later tried to return a result. Fix: move cleanup before the call_canceling check so it always runs. Only the INTERRUPT message is conditional on call_canceling support. Port of upstream crossbar PR crossbario#2153 (fixes issue crossbario#2133). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Port of upstream PR crossbario#2153: when a caller disconnects during an in-flight RPC, invocation cleanup was skipped if the callee did not support call_canceling (due to an early continue). This left stale entries in _invocations and _callee_to_invocations, causing errors when the callee later tried to return a result. Fix: move cleanup before the call_canceling check so it always runs. Only the INTERRUPT message is conditional on call_canceling support. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>


a rundown on what the issue is and how it impacts the callee:
Exception Flow: Caller Disconnect Causes Callee Session Crash
When a caller disconnects during an in-flight RPC, the callee's session can be terminated due to unhandled exception propagation:
The Problem
YIELDmessage with the resultprocessYield()indealer.pytries to send result tocaller._transportwhich isNonerouter.process()router.process()re-raisesProtocolError(see router.py#L355-356)WampWebSocketProtocol.onMessage()ProtocolErrorand calls_bailout()withCLOSE_STATUS_CODE_PROTOCOL_ERRORCode Path
Impact
Any
ProtocolErrorraised in the dealer causes the entire session's WebSocket connection to be closed, which is catastrophic for the callee who did nothing wrong.The Fix
Clean up invocation tracking when the caller detaches, so that when the callee later calls
processYield():_invocationsprocessYield()simply logs a debug message and returnsNoneThe Test
The test creates the scenario sketched above and expects the dealer.py to not raise an error in step 4 (processYield).
Currently without the fix the test does not pass.