fix(transport): Handle HTTP 413 with actionable log and use send_error for HTTP errors#5115
fix(transport): Handle HTTP 413 with actionable log and use send_error for HTTP errors#5115
Conversation
…r for HTTP errors Log a specific, actionable error message when Relay returns HTTP 413 (Content Too Large) instead of the generic "Request failed" message. The message suggests reducing event/breadcrumb/attachment sizes and mentions the `SentryOptions.onOversizedEvent` callback. Also switch the client report discard reason for all HTTP 4xx/5xx errors (except 429) from `network_error` to `send_error`, matching the client reports spec and aligning with sentry-python and sentry-cocoa. Fixes GH-5050 Co-Authored-By: Claude <noreply@anthropic.com>
🚨 Detected changes in high risk code 🚨High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:
|
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. Bug Fixes 🐛
🤖 This preview updates automatically when you update the PR. |
Co-Authored-By: Claude <noreply@anthropic.com>
🚨 Detected changes in high risk code 🚨High-risk code has higher potential to break the SDK and may be hard to test. To prevent severe bugs, apply the rollout process for releasing such changes and be extra careful when changing and reviewing these files:
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| "Envelope was discarded by the server because it was too large." | ||
| + " Consider reducing the size of events, breadcrumbs, or attachments." | ||
| + " You can use the `SentryOptions.onOversizedEvent` callback" | ||
| + " to customize how oversized events are handled."; |
There was a problem hiding this comment.
Duplicate 413 error message logged in AsyncHttpTransport path
Low Severity
When AsyncHttpTransport handles a 413 response, the identical actionable error message gets logged twice. AsyncHttpTransport.send() calls connection.send() which calls HttpConnection.readAndLog() — that logs the 413-specific message first. Then control returns to AsyncHttpTransport, which logs the same message again. Before this change, the two log sites used different message strings, so duplication was less noticeable. Now both emit the same long user-facing guidance, which is confusing.
Additional Locations (1)
Performance metrics 🚀
|
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| d15471f | 361.89 ms | 378.07 ms | 16.18 ms |
| 6edfca2 | 305.52 ms | 432.78 ms | 127.26 ms |
| ed33deb | 337.52 ms | 484.06 ms | 146.54 ms |
| f064536 | 349.86 ms | 417.66 ms | 67.80 ms |
| d217708 | 409.83 ms | 474.72 ms | 64.89 ms |
| 23d6b12 | 354.10 ms | 408.38 ms | 54.28 ms |
| ad8da22 | 362.98 ms | 453.94 ms | 90.96 ms |
| ee747ae | 374.71 ms | 455.18 ms | 80.47 ms |
| 33a08cc | 267.08 ms | 340.45 ms | 73.37 ms |
| 2124a46 | 319.19 ms | 415.04 ms | 95.85 ms |
App size
| Revision | Plain | With Sentry | Diff |
|---|---|---|---|
| d15471f | 1.58 MiB | 2.13 MiB | 559.54 KiB |
| 6edfca2 | 1.58 MiB | 2.13 MiB | 559.07 KiB |
| ed33deb | 1.58 MiB | 2.13 MiB | 559.52 KiB |
| f064536 | 1.58 MiB | 2.20 MiB | 633.90 KiB |
| d217708 | 1.58 MiB | 2.10 MiB | 532.97 KiB |
| 23d6b12 | 1.58 MiB | 2.10 MiB | 532.31 KiB |
| ad8da22 | 1.58 MiB | 2.29 MiB | 719.83 KiB |
| ee747ae | 1.58 MiB | 2.10 MiB | 530.95 KiB |
| 33a08cc | 1.58 MiB | 2.12 MiB | 555.28 KiB |
| 2124a46 | 1.58 MiB | 2.12 MiB | 551.51 KiB |


Relay now returns HTTP 413 instead of HTTP 400 for oversized envelopes
(relay#5474). Previously
the SDK treated 413 like any other 4xx error with a generic log message,
giving users no indication of why their data was dropped.
This adds a specific, actionable error message when receiving HTTP 413,
suggesting users reduce the size of events, breadcrumbs, or attachments,
and pointing them to the
SentryOptions.onOversizedEventcallback.Also switches the client report discard reason for all HTTP 4xx/5xx errors
(except 429) from
network_errortosend_error, matching theclient reports spec and
aligning with sentry-python and sentry-cocoa.
network_erroris nowreserved for actual connectivity failures (IOException, transport gate
not connected).
Changes:
DiscardReason.java— AddedSEND_ERROR("send_error")HttpConnection.java— 413-specific log message inreadAndLog()AsyncHttpTransport.java— 413-specific log message +SEND_ERRORfor all HTTP errorsApacheHttpClientTransport.java— Same as aboveFixes #5050