fix(node): Avoid duplicated sentry-trace and baggage headers on fetch requests#19960
fix(node): Avoid duplicated sentry-trace and baggage headers on fetch requests#19960
sentry-trace and baggage headers on fetch requests#19960Conversation
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Deps
Bug Fixes 🐛Cloudflare
Core
Deps
Other
Internal Changes 🔧Deps Dev
Nuxt
Other
🤖 This preview updates automatically when you update the PR. |
| if (headerName === SENTRY_BAGGAGE_HEADER) { | ||
| // merge the initial entry into the later occurance so that we keep the initial sentry- values around. | ||
| // all other non-sentry values are merged | ||
| const merged = mergeBaggageHeaders(headers[i + 1] as string, headers[firstIndex + 1] as string); |
There was a problem hiding this comment.
Bug: The mergeBaggageHeaders function is called with arguments in the wrong order, causing user-defined non-Sentry baggage values to be overwritten by automatically-appended OTel baggage.
Severity: HIGH
Suggested Fix
Swap the arguments in the mergeBaggageHeaders call within _deduplicateArrayHeader. The initial, user-set header (headers[firstIndex + 1]) should be the first argument, and the later, OTel-appended header (headers[i + 1]) should be the second. This will ensure that the user's non-Sentry baggage values are preserved.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: packages/node-core/src/utils/outgoingFetchRequest.ts#L154
Potential issue: In `_deduplicateArrayHeader`, the call to `mergeBaggageHeaders`
incorrectly prioritizes non-Sentry values from later baggage headers. The function is
called with the OTel-appended header as the first argument (`existing`) and the
user-defined header as the second (`new`). The merging logic only adds non-Sentry keys
from the `new` header if they don't already exist in the `existing` one. This causes
user-defined non-Sentry baggage values to be silently overwritten by values from the
automatically-appended OTel header, which contradicts the intended behavior of
preserving all user-set values.
Did we get this right? 👍 / 👎 to inform future reviews.
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
c4c5fbb to
a11ca57
Compare
This PR fixes a bunch of issues within our node fetch integration for tracing header edge cases.
mergeBaggageHeaderswould mix upsentry-entries from both headers creating completely inconsistent baggage entries. We must not mix up entries as otherwise the propagated DSC values would be inconsistent. This would interfere with dynamic sampling.addTracePropagationHeadersToFetchRequestwould correctly avoid setting asentry-traceheader if a previous one existed but happily still add newbaggageand optionallytraceparentheaders. Again causing inconsistent data betweensentry-traceand the other two values (e.g. distinct trace ids across the headers in one request). I'd argue that as soon as asentry-traceheader is found, we should no longer add any new headers.sentry-entries would cause multiplebaggageheaders to be present. This was due to insufficient deduplication in our own header adding logic. What makes this much worse though is that we cannot stop OTel's UndiciInstrumentation from injecting headers.Open issue: If users manually add a
baggageheader, we have to deal with 3 competing entries:Right now, this PR correctly dedupes BUT prefers 2 over 1 and 3. There's a case to be made that 1 should be preferred. Also according to a comment in the code, 3 should be preferred over 2. Still need to fix that. Therefore setting this to draft.
closes #19158