ref(node)!: Remove deprecated fastify exports, deprecate setupFastifyErrorHandler - #23460
Merged
Merged
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
size-limit report 📦
|
mydea
marked this pull request as ready for review
August 20, 2026 10:53
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
mydea
marked this pull request as draft
August 20, 2026 11:33
mydea
force-pushed
the
fn/streamline-fastify
branch
from
August 20, 2026 13:37
3004b8c to
3a04de5
Compare
mydea
marked this pull request as ready for review
August 20, 2026 13:55
mydea
force-pushed
the
fn/streamline-fastify
branch
from
August 21, 2026 09:50
3a04de5 to
07fbd58
Compare
isaacs
requested changes
Aug 23, 2026
isaacs
left a comment
isaacs
left a comment
Member
There was a problem hiding this comment.
Found a few nits and questions/cleanup opportunities, mostly fairly low severity.
This is a really nice cleanup, very deep cuts. Love to see it!
The only blocking issue imo is that Fastify will silently not track errors anymore unless tracing is enabled, and requiring someone to specifically opt into the integration isn't meaningfully easier than requiring them to attach a custom error handler. I'd recommend just having it turned on all the time.
Also, there's some orphaned e2e test files that I think can be deleted:
dev-packages/e2e-tests/test-applications/node-fastify-3/playwright.override.config.mjsdev-packages/e2e-tests/test-applications/node-fastify-4/playwright.override.config.mjsdev-packages/e2e-tests/test-applications/node-fastify-5/playwright.override.config.mjs
Member
Author
Member
|
Just quickly cross-referencing this other Fastify PR here: |
mydea
force-pushed
the
fn/streamline-fastify
branch
from
August 24, 2026 12:26
129ac3e to
ffd446a
Compare
mydea
force-pushed
the
fn/streamline-fastify
branch
from
August 24, 2026 12:51
ffd446a to
3024abc
Compare
Member
mydea
force-pushed
the
fn/streamline-fastify
branch
from
August 26, 2026 07:18
3024abc to
88fc5d8
Compare
isaacs
approved these changes
Aug 26, 2026
isaacs
left a comment
isaacs
left a comment
Member
There was a problem hiding this comment.
All concerns addressed! LGTM! 🚢
mydea
force-pushed
the
fn/streamline-fastify
branch
from
August 27, 2026 06:57
d6cde9e to
95e8de1
Compare
s1gr1d
added a commit
that referenced
this pull request
Aug 27, 2026
Resolves conflicts with #23460, which consolidated Fastify onto a single channel-based `fastifyIntegration` and moved everything out of `packages/node/src/integrations/tracing/fastify/`. Conflict resolutions (all modify/delete — upstream deletion accepted): - The three e2e `app-handle-error-override.ts` apps: #23460 deleted them and moved override coverage into node-integration-tests. - `packages/node/src/integrations/tracing/fastify/index.ts`: deleted, the integration now lives in `@sentry/server-utils`. - `docs/migration/v11-end-state.md`: deleted by #23623, which folded the guide into MIGRATION.md. The Fastify entries were ported there. Reapplied on top: `setupFastifyErrorHandler` no longer accepts `shouldHandleError`. After removing `setShouldHandleError`, forwarding the option was the shim's only remaining job, so it is now a deprecated no-op kept purely so existing `setupFastifyErrorHandler(app)` calls do not break. The node-integration-test that covered the option was repointed at `fastifyIntegration({ shouldHandleError })`. Co-Authored-By: Opus 5 <noreply@anthropic.com>
47 tasks
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
4 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.
This consolidates the Fastify instrumentation onto a single, diagnostics-channel-based
fastifyIntegrationand removes the deprecated/unneeded Fastify exports.Node, Bun, and Elysia now use the channel-based
fastifyIntegrationfrom@sentry/server-utils, and the old Node-specific integration (which wrapped theOpenTelemetry Fastify instrumentation) is deleted. A single plugin now instruments
Fastify v3.21–v5, including error capture, so error handling no longer depends on
the Fastify version or on the user wiring anything up manually.
What changes for users
setupFastifyErrorHandler(app)is no longer required — errors are capturedautomatically once
fastifyIntegration()is added. It is now deprecated and keptonly as a thin shim that forwards a
shouldHandleErrorcallback to the integration.shouldHandleErroris configured directly onfastifyIntegration({ shouldHandleError })for all supported versions. Previously this only applied to v5, with v3/v4 going through
setupFastifyErrorHandler.instrumentFastifyandhandleFastifyErrorexports wereremoved. They are no longer needed now that the integration instruments and captures on
its own.
Notable decisions
fastify.initialization/ error diagnostics channels lets us instrument v3.21 → v5uniformly, without per-version branching and without asking users to register an error
handler by hand.
diagnostics channel and the
onErrorhook. Rather than leaning oncaptureException'serror-object dedupe, we mark the request with a non-enumerable symbol once captured and
bail out on the second path. Errors that reach only one path (thrown in an
onRequesthook, or on v3/v4 which have no channel) are still captured exactly once.
Root cause note (instance patching)
The plugin is applied synchronously from the
fastify.initializationchannel ratherthan via
instance.register().register()defers work to the boot phase (listen()/ready()), butaddHookruns immediately — so hooks a user adds synchronously beforelisten()would otherwise slip through un-instrumented. Patching synchronously (the initchannel fires before
Fastify()returns) ensures every hook is wrapped. TheonErrorhook is registered as an async hook so Fastify awaits it correctly and the error response
is not left hanging.
Tests
app-handle-error-override.tsE2E apps and theirplaywright.override.config.mjsfrom thenode-fastify-3/4/5test apps.scenario-error-handler.mjs),and added a no-tracing scenario plus a regression case for a hook added synchronously
before
listen().Migration guide updated for both the
setupFastifyErrorHandlerdeprecation and theremoved exports.