Repository navigation
fix(node): Don't mark fetch spans as errors when the caller aborts - #25129
Merged
andreiborza merged 3 commits intoOct 12, 2026
Merged
Conversation
4ktLuffy
requested review from
andreiborza and
mydea
and removed request for
a team
October 7, 2026 10:35
andreiborza
approved these changes
Oct 12, 2026
andreiborza
left a comment
Member
There was a problem hiding this comment.
Hi @4ktLuffy, thanks for fixing this. LGTM
andreiborza
added a commit
that referenced
this pull request
Oct 12, 2026
…rts (#25260) ## What Outgoing `node:http` spans no longer get an error status when the caller aborts the request (for example with `AbortController.abort()`). If a response already arrived, the span keeps the status of that response. ## Why A caller abort is not a request failure, and it showed false `http.client` errors (for example for axios cancellation). This matches the fetch fix in #25129. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
andreiborza
added a commit
that referenced
this pull request
Oct 12, 2026
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #25129 Co-authored-by: andreiborza <168741329+andreiborza@users.noreply.github.com>
andreiborza
pushed a commit
that referenced
this pull request
Oct 12, 2026
#25273) Backport of: #25129 ## Differences to the original PR - The fix applies to `packages/node-core/src/integrations/node-fetch/undici-instrumentation.ts`. On v10 the vendored undici instrumentation is in `@sentry/node-core`, not `@sentry/node`. The `onError` change itself is the same. - Added `// eslint-disable-next-line typescript/no-deprecated` above the `error.code === DOMException.ABORT_ERR` check. Without it, v10's `typescript/no-deprecated` lint rule fails on `DOMException.code`. Runtime behavior does not change. - The tests are in a new file, `packages/node-core/test/integrations/undici.test.ts`. v10 has no `undici.test.ts` to extend. The new file uses the same mock setup as the develop test file (`@sentry/core` `startInactiveSpan`/`getClient`, `outgoingFetchRequest`) and contains only the new `request errors` cases. It leaves out the existing develop-only QUERY-method/span-naming tests. <!-- junior-request-attribution:start --> via Junior system actor `junior`. <!-- junior-request-attribution:end --> <!-- junior-session-footer:start --> <!-- junior-conversation-id:agent-dispatch%3Adispatch_c21e073eaf1d6b2a655e346024498ce1 --> -- [View Junior Session](https://junior-prod.sentry.dev/conversations/agent-dispatch%3Adispatch_c21e073eaf1d6b2a655e346024498ce1) [[Sentry]](https://sentry.sentry.io/explore/conversations/agent-dispatch%3Adispatch_c21e073eaf1d6b2a655e346024498ce1/?project=4510944073809921) <!-- junior-session-footer:end --> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
47 tasks done
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
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.
A
fetch()span that already got a 200 response ends up withstatus: errorwhen the caller cancels the body stream (reader.cancel()) or callsAbortController.abort()after the headers arrived. undici reports that asundici:request:errorwith anAbortErrorinstead ofundici:request:trailers, andonErrorin the undici instrumentation setsSPAN_STATUS_ERRORfor every error.This ports the check from upstream OpenTelemetry (open-telemetry/opentelemetry-js-contrib#3488, "do not record aborted requests as errors"): if the error is an
AbortError, or aDOMExceptionwithABORT_ERR, the span is ended without touching its status. Other errors (connection reset,TypeError: fetch failed, ...) still set the error status as before. I updated the NOTE comment aboveonErrorto say so.This matters for clients that read a stream and then close it as part of normal operation. For example the MCP TypeScript SDK closes its event stream on client close, so every healthy session showed
http.clienterror spans.Repro
Before (11.4.0): the fully read request is
ok, the cancelled one iserrorwithhttp.response.status_code200. Same withAbortController.abort()after the headers arrive.After (this branch, built with
yarn build:dev:filter @sentry/node): both areok.Tests
Added unit tests to
packages/node/test/integrations/undici.test.tsthat publish theundici:request:create,undici:request:headers(200) andundici:request:errordiagnostics channel messages:AbortError,DOMExceptionnamedAbortError,DOMExceptionwith only theABORT_ERRcode) end the span without an error statusTypeErrorand anECONNRESETerror still set the error statuscd packages/node && yarn vitest run test/integrations/undici.test.ts: without the fix 3 of 10 fail (the abort cases), with the fix 10 of 10 pass.oxfmt --checkandoxlint --type-awareare clean on both files.yarn lint) & (yarn test). (Ran the changed test file, oxfmt and oxlint on the changed files; not the full suite.)