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
Fix kernel interrupt on client disconnect with FastAPI 0.136.3
Bumping FastAPI 0.111.0 -> 0.136.3 pulls in Starlette 1.2.1, which broke
the #213 disconnect->interrupt behavior. Starlette >= 1.0 takes a new
StreamingResponse path for ASGI spec_version >= 2.4 (advertised by
uvicorn 0.30.1): it no longer runs listen_for_disconnect concurrently and
no longer cancels the response body iterator on http.disconnect. The
interrupt relied on that cancellation, so an abandoned execution was never
interrupted and the next execution blocked behind it and timed out.
This was the only failing test in both SDKs on the Renovate bump (#207):
- js: tests/interrupt.test.ts > subsequent execution works after client timeout
- python: test_async_interrupt.py::test_subsequent_execution_works_after_client_timeout
Detect the disconnect explicitly: thread the Request into execute(), and on
each keepalive tick poll request.is_disconnected(). When it flips, raise an
internal _ClientDisconnected, interrupt the kernel, and stop streaming. The
old cancellation path is still handled for older Starlette.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Interrupt the kernel when the HTTP client disconnects mid-execution so the per-context lock is released and subsequent executions aren't blocked (#213). On the latest FastAPI (0.136.3) / Starlette (1.2.1), `StreamingResponse` no longer cancels the response body iterator on `http.disconnect` (ASGI spec 2.4+), so the server now detects the disconnect itself by polling `request.is_disconnected()` while streaming and interrupts the kernel.
0 commit comments