feat(develop): client report handling of HTTP 413#16275
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
coolguyzone
reviewed
Feb 5, 2026
| reports getting rate limited, but the SDKs shouldn't worry about this edge case as | ||
| this feature is best-effort. | ||
|
|
||
| ### Dealing with network failures |
Contributor
There was a problem hiding this comment.
Suggested change
| ### Dealing with network failures | |
| ### Dealing With Network Failures |
coolguyzone
approved these changes
Feb 5, 2026
|
|
||
| The party that drops an envelope item **MUST** record and report it. | ||
|
|
||
| The `send_error` reason is reserved for client error outcomes only. Server related codes **SHOULD NOT** be recorded since the server already tracks these. However, Relay does not always record an outcome for oversized envelopes (413), so SDKs **SHOULD** accept the trade-off of potential double counting for `RequestEntityTooLarge` (413) responses to ensure all discarded events are captured. `TooManyRequests` (429) responses **MUST** be skipped since the server records these outcomes. |
Member
There was a problem hiding this comment.
I'm not 100% sure if send_error is really only reserved for clients. If double checked, then we can keep it.
Comment on lines
+167
to
+171
| In summary: | ||
|
|
||
| - **HTTP 2xx**: Successful send—no client report needed. | ||
| - **HTTP 4xx/5xx (except 429)**: Discard the envelope and record a client report with reason `send_error`. | ||
| - **HTTP 429**: Discard the envelope without recording a client report. |
Member
There was a problem hiding this comment.
I don't think it's a good idea to have HTTP status codes now here and also here https://develop.sentry.dev/sdk/expected-features/#dealing-with-network-failures
I think we should focus on client reports and only reference the https://develop.sentry.dev/sdk/expected-features/#dealing-with-network-failures here. Otherwise, we have to have two pages explaining similar concepts, and they will diverge again.
WDYT?
philipphofmann
approved these changes
Feb 6, 2026
Member
philipphofmann
left a comment
philipphofmann
left a comment
There was a problem hiding this comment.
LGTM, with two suggestions.
|
|
||
| ### Dealing with Network Failures | ||
|
|
||
| The party that drops an envelope item **MUST** record and report it. SDKs can assume client reports are never rate limited. |
Member
There was a problem hiding this comment.
I would keep the extra context.
Suggested change
| The party that drops an envelope item **MUST** record and report it. SDKs can assume client reports are never rate limited. | |
| The party that drops an envelope item **MUST** record and report it. SDKs can assume client reports are never rate limited. The server is minimizing the possibility of client reports getting rate limited, but the SDKs shouldn't worry about this edge case as this feature is best-effort. |
| reports getting rate limited, but the SDKs shouldn't worry about this edge case as | ||
| this feature is best-effort. | ||
|
|
||
| ### Dealing with Network Failures |
Member
There was a problem hiding this comment.
I'm not sure if the extra heading is still required, because the section is so small now.
Suggested change
| ### Dealing with Network Failures |
|
|
||
| The party that drops an envelope item **MUST** record and report it. SDKs can assume client reports are never rate limited. | ||
|
|
||
| For details on which HTTP status codes require a client report and which discard reasons to use, see [Dealing with Network Failures](/sdk/expected-features/#dealing-with-network-failures). |
jaffrepaul
pushed a commit
that referenced
this pull request
Feb 9, 2026
<!-- Use this checklist to make sure your PR is ready for merge. You may delete any sections you don't need. --> ## DESCRIBE YOUR PR Improve explanation for handling client report outcomes in cases of network errors and include explanation for client report handling of 413. ## IS YOUR CHANGE URGENT? Help us prioritize incoming PRs by letting us know when the change needs to go live. - [ ] Urgent deadline (GA date, etc.): <!-- ENTER DATE HERE --> - [ ] Other deadline: <!-- ENTER DATE HERE --> - [x] None: Not urgent, can wait up to 1 week+ ## SLA - Teamwork makes the dream work, so please add a reviewer to your PRs. - Please give the docs team up to 1 week to review your PR unless you've added an urgent due date to it. Thanks in advance for your help! ## PRE-MERGE CHECKLIST *Make sure you've checked the following before merging your changes:* - [ ] Checked Vercel preview for correctness, including links - [ ] PR was reviewed and approved by any necessary SMEs (subject matter experts) - [ ] PR was reviewed and approved by a member of the [Sentry docs team](https://github.com/orgs/getsentry/teams/docs) ## LEGAL BOILERPLATE <!-- Sentry employees and contractors can delete or ignore this section. --> Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms. ## EXTRA RESOURCES - [Sentry Docs contributor guide](https://docs.sentry.io/contributing/)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DESCRIBE YOUR PR
Improve explanation for handling client report outcomes in cases of network errors and include explanation for client report handling of 413.
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes:
LEGAL BOILERPLATE
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.
EXTRA RESOURCES