feat(node)!: Always report the encoded body size on HTTP spans - #23576
Open
msonnb wants to merge 2 commits into
Open
feat(node)!: Always report the encoded body size on HTTP spans#23576msonnb wants to merge 2 commits into
msonnb wants to merge 2 commits into
Conversation
Contributor
size-limit report 📦
|
msonnb
force-pushed
the
ms/http-attrs-body-sizes
branch
from
August 25, 2026 13:07
5b4383f to
d4a417c
Compare
msonnb
changed the title
msonnb
changed the title
msonnb
force-pushed
the
ms/http-attrs-body-sizes
branch
from
August 25, 2026 13:48
d4a417c to
4a220fd
Compare
msonnb
force-pushed
the
ms/http-attrs-body-sizes
branch
from
August 25, 2026 14:01
4a220fd to
376d102
Compare
msonnb
force-pushed
the
ms/http-attrs-body-sizes
branch
from
August 25, 2026 14:38
376d102 to
100e344
Compare
Member
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 100e344. Configure here.
msonnb
marked this pull request as ready for review
August 25, 2026 14:44
msonnb
requested review from
JPeer264 and
isaacs
and removed request for
a team
August 25, 2026 14:44
msonnb
force-pushed
the
ms/http-attrs-body-sizes
branch
from
August 25, 2026 14:46
100e344 to
684378f
Compare
Part of the v11 migration away from attributes `@sentry/conventions` marks deprecated. Stacked on the `http.*` renames. `http.target` carried the pathname *and* the query, while `url.path` is the pathname only. The core server span set neither `url.query` nor `url.fragment`, so dropping `http.target` would have lost the query — it now sets both, which the node server span already did. Consumers that matched on `http.target` were repointed at `url.path`: the react-router low-quality-transaction filter and the TanStack Start tunnel-route filter, both `ignoreSpans` rules against our own spans that would otherwise have silently stopped matching. The Next.js readers keep `http.target` as a fallback behind a `url.path` primary, since they also see spans from a user's own OpenTelemetry instrumentation. All other read-side fallbacks are untouched for the same reason. `no-unfiltered-url-attributes` no longer guards `http.target`: nothing sets it, and its replacement `url.path` is a bare pathname with no query to filter. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Part of the v11 migration. Stacked on the `http.target` PR. The attribute renames landed in the first PR of the stack; this one is the behavior change behind them. Node HTTP spans read the `content-length` header and then reported it as either the encoded or the decoded body size, branching on whether a `content-encoding` header was present. Neither attribute was set on every span, so a query against either one only ever saw part of a user's traffic. `content-length` is the encoded size whether or not a content encoding is applied, so it now always maps to `http.request.body.size` / `http.response.body.size`. The decoded size cannot be derived from `content-length`, so Node HTTP spans no longer set `http.request.body.decoded_size` or `http.response.body.decoded_size`. Browser resource spans still report the latter, where the Resource Timing API measures it directly. Deriving the decoded size from `content-length` when no encoding is applied was considered and rejected: it would populate the attribute only where it duplicates the encoded size, and leave it empty exactly where it carries information, which makes any query over it a biased sample. Measuring the decompressed stream would be the real fix and is out of scope here. The three copies of the `content-length` parsing are now one `getContentLengthFromHeaders` util in `@sentry/core`, whose docblock holds the encoded-size rule so it is not restated at each call site. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
msonnb
force-pushed
the
ms/http-attrs-body-sizes
branch
from
August 25, 2026 14:52
684378f to
2e7b1a9
Compare
logaretm
approved these changes
Aug 25, 2026
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
What
Always set
http.(request|response).body.sizeinstead of.sizeand.decoded_sizein HTTP server spans. Browser resource spans are untouched and still report the latter, where the Resource Timing API measures it directly.Why
The
content-lengthheader always reports the encoded body size, and we only set the.decoded_sizeattribute whencontent-encodingwasidentity, i.e. there was no encoding and the "decoded" size would equal the encoded size. I'd argue that "decoded" or "uncompressed" has no real meaning and thus value in this case and that we should just always sethttp.request.body.size.part of #18895