You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e1abcac
Browse filesBrowse the repository at this point in the historyBrowse files
fix(connection): keep request responses out of the handler's cancellation
Two races could still lose the response to a cancelled request:
- A `$/cancel_request` read in the same buffer as its request cancelled the
request task before it first ran, so the coroutine that would have sent
`-32800` never executed.
- A late or repeated `$/cancel_request` arriving while the response was being
sent cancelled that send, so the peer got no response at all.
Each incoming request now runs its handler in its own task, which is the only
thing `$/cancel_request` targets. A separate supervised task waits for the
handler with `asyncio.wait` and sends its result, or `-32800` if the handler
was cancelled. `close()` still cancels both, so shutdown never waits on a
blocked send, and the `Task.uncancel()` / closed-send special cases are no
longer needed.
Also document request cancellation in the quickstart and state that a
cancelled handler answers with its result or `-32800`.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
0 commit comments