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
In Sentry, we observed slow transactions running for up to ~1 minute that then failed with 400 Bad Request. We suspect these are caused by unusually large request payloads, but the HTTP request logger middleware currently does not log request payload size — so there is no way to confirm this by correlating payload size with a specific request (via its correlation ID) in Sentry or AWS CloudWatch.
Describe the solution you'd like
Modify app/core/middleware.py (_log_http_request) to:
Capture the request body size from the Content-Length header (0 when absent/malformed).
Add it as the http.request.body.size span attribute (OTel semantic convention) so it reaches Sentry via the OTel instrumenter.
Include request_body_size and correlation_id in the access log line, which flows to both Sentry (LoggingIntegration) and AWS CloudWatch (stdout log shipping).
Emit a http.server.request.body.size distribution metric to Sentry alongside the existing request count/duration metrics.
This will let us confirm (or rule out) the large-payload hypothesis for the slow 400 transactions.
changed the title [-]Log request payload size per correlation ID for Sentry and CloudWatch[/-][+]Middleware: Log request payload size[/+]on Aug 26, 2026
Activity
[-]Log request payload size per correlation ID for Sentry and CloudWatch[/-][+]Middleware: Log request payload size[/+]github-actions commentedon Aug 27, 2026
🎉 This issue has been resolved in version 1.5.0-main.13 🎉
The release is available on GitHub release
Your semantic-release bot 📦🚀