FastAPI 0.140.13 fixes status codes on streaming endpoints

FastAPI's 0.140.x line closed out July with a fix that matters for anyone building streaming endpoints on top of the framework: a bug where the status_code set on a StreamingResponse or JSONL response was silently ignored for Server-Sent Events and newline-delimited JSON streams, with the framework always returning 200 regardless of what the handler specified. That is a meaningful correctness gap for APIs that stream partial results, live updates, or long-running job progress back to clients, since callers rely on HTTP status codes to distinguish a stream that completed successfully from one that failed partway through or needs to signal a non-200 condition upfront. The fix restores the expected behavior so the declared status code is honored for these streaming response types. It arrived alongside a run of other 0.140.x patches that reworked how FastAPI derives request body fields from a route's dependency graph and how it flattens dependency parameters, changes aimed at trimming memory overhead and improving how routes appear in the generated OpenAPI schema, particularly for routes with deeply nested or shared dependencies. None of this is flashy, but FastAPI underpins a huge share of production Python APIs, including ones that increasingly serve as the backend for AI agent tool-calling and event streams, so a quiet correctness fix to SSE/JSONL status codes has outsized practical value for teams who assumed the status code they set was actually being sent to clients. It is worth a version bump for anyone running SSE-based endpoints in production, since the wrong status code can silently break client-side retry and error-handling logic.

Source

View on ShipDigest