Skip to content

feat(develop): client report handling of HTTP 413 #16275

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
giortzisg merged 3 commits into from
Feb 6, 2026
+3 −9
Merged

feat(develop): client report handling of HTTP 413 #16275

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7a3160b
feat(develop): client report handling of HTTP 413
giortzisg Feb 5, 2026
99a7023
chore: link only the network failures page
giortzisg Feb 6, 2026
1357d78
chore: add more details
giortzisg Feb 6, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 3 additions & 9 deletions develop-docs/sdk/telemetry/client-reports.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -157,15 +157,9 @@ SDKs **SHOULD** minimize unnecessary HTTP requests and **MUST NOT** send an enve

SDKs **MAY** keep track of discarded events in the transport. Once SDKs implement the [telemetry processor](/sdk/telemetry/telemetry-processor/), they **SHOULD** implement client reports tracking outside the transport, since data can be dropped in multiple places throughout the SDK. The [telemetry scheduler](/sdk/telemetry/telemetry-processor/#telemetry-scheduler) is then responsible for passing aggregated client reports to the transport. The telemetry scheduler still **MUST** adhere to the requirements above.

The one who drops an envelope item must record and report it. If the server drops
an envelope item, for example, with the response 429, the client SDK must not record
this as the server already does. Still, the SDK must record lost envelope items
when dropping them itself, for example, caused by an active rate limit. SDKs can put
a simple optional check for HTTP status codes in place where any code `>= 400` except
`429` will be recorded as `send_error`. The client SDKs can assume that client
reports never get 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.
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.

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).
Copy link
Member

@philipphofmann philipphofmann Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, better now thanks.


### Configuration

Expand Down