Fiddle: update database connection middleware to support streaming apis#133
Conversation
There was a problem hiding this comment.
Pull request overview
Updates middleware and request authorization typing to better support streaming endpoints, ensuring request-scoped resources remain available while the response body is being streamed.
Changes:
- Reworked
DatabaseConnectionMiddlewarefromBaseHTTPMiddlewareto raw ASGI to keep the DB context open through streaming responses. - Updated
authorize_bearer_jwtdecorator typing to allow endpoints that return async iterators (streaming). - Removed the
make type-checkstep from the Dockerfile build.
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| core/api/middleware/database_connection_middleware.py | Switches to raw ASGI middleware so DB context survives streaming response bodies. |
| core/api/authorizer.py | Expands decorator typing/handling to support streaming handlers returning async iterators. |
| Dockerfile | Removes type-check from image build (impacts where type-check enforcement occurs). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| return | ||
| async with self.database.create_context_connection(): | ||
| response = await call_next(request) | ||
| return response | ||
| await self.app(scope, receive, send) |
There was a problem hiding this comment.
create_context_connection() uses engine.begin() (a transaction) and this middleware now keeps that transaction open until the streaming response fully completes. For long-lived streams this can hold locks/retain MVCC snapshots and tie up a pooled connection for the entire client session. Consider using a non-transactional connection context for request-scoped connections (e.g., engine.connect()), or splitting streaming endpoints so DB work completes (and transaction closes) before yielding to the client.
Description
Screenshots:
Checklist: