Skip to content

Fastify 5 integration: reply.statusCode  is always 200 in  shouldHandleError , making docs example unusable #18418

Description

@irsooti

Is there an existing issue for this?

How do you use Sentry?

Self-hosted/on-premise

Which SDK are you using?

@sentry/node

SDK Version

10.29.0

Framework Version

Fastify 5.4.0

Link to Sentry event

No response

Reproduction Example/SDK Setup

Hi,
while integrating Sentry with Fastify I ran into a few problems with the Fastify integration, mainly:

  • Handling Fastify errors (for example validation errors, which are “handled” in theory)
  • Handling errors from  @fastify/sensible  (which are handled, but only from 500 upwards)

The docs suggest a very simple approach: check reply.statusCode  inside  shouldHandleError  to decide whether an error should be captured. However, in my case  reply.statusCode  is always 200  inside shouldHandleError.

I do not override the status code anywhere, and I do not have any custom error handler that would reset it. This was quite frustrating because the recommended pattern in the docs becomes effectively unusable.
Because of this, I had to fall back to a more ad‑hoc implementation, where I decide what to send to Sentry based only on the error type/name, instead of the HTTP status code. This is what I ended up with (simplified):

Sentry.init({
    enabled: env.SENTRY_ENABLED,
    dsn: env.SENTRY_DSN,
    environment: env.SENTRY_ENVIRONMENT,
    release: `${env.npm_package_name}-${env.npm_package_version}`,
    sampleRate: env.SENTRY_SAMPLE_RATE,
    integrations: [
        Sentry.fastifyIntegration({
            shouldHandleError(err) {
                // Ignore 4xx from @fastify/sensible
                if (SENSIBLE_4XX_ERRORS.includes(err.name)) {
                    return false;
                }

                // Ignore all Fastify 4xx errors
                if (shouldIgnoreFastifyError(err)) {
                    return false;
                }

                return true;
            },
        }),
    ],
    beforeSend: (event, hint) => {
        if (
            hint.originalException instanceof Error &&
            SENSIBLE_5XX_ERRORS.includes(hint.originalException.name)
        ) {
            event.exception?.values?.forEach((value) => {
                value.mechanism = {
                    type: 'fastify.sensible',
                    handled: true,
                };
            });
        }

        return event;
    },
});

This works and should not drop important errors, but it is much less granular and much less clear than checking  reply.statusCode  as shown in the docs. It also means I cannot easily separate 4xx vs 5xx just by looking at the response.
A few questions / suggestions:

  • Is  reply.statusCode  supposed to be meaningful inside  shouldHandleError  for the Fastify integration, or is it expected to be  200  there?
  • If this is expected, the docs example using  reply.statusCode  is at least misleading and should probably be updated or clarified.
  • If this is not expected, it might be a bug either in the integration or in how the Fastify reply object is passed.

Steps to Reproduce

Just tried as documentation says:

Sentry.init({
    enabled: env.SENTRY_ENABLED,
    dsn: env.SENTRY_DSN,
    environment: env.SENTRY_ENVIRONMENT,
    release: `${env.npm_package_name}-${env.npm_package_version}`,
    sampleRate: env.SENTRY_SAMPLE_RATE,
    integrations: [
        Sentry.fastifyIntegration({
            shouldHandleError(err) {
              // what you suggested
            },
        }),
    ]
    },
});

Expected Result

  • Ignore validation errors;
  • Ignore 400;

Actual Result

No logs, but always 200

Additional Context

No response

Priority

React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.

Activity

  1. linear commented on Dec 5, 2025

    @linear
  2. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Dec 5, 2025
  3. JPeer264 commented on Dec 9, 2025

    @JPeer264
    Member

    Hey thanks for the issue. It seems that this might be an issue in Fastify (fastify/fastify#6409). Before I take actions on the docs, I'd like to clarify on the actual behavior from Fastify.

    However, you can set the status before you send an error to actually get the correct statusCode:

    fastify.get('/error-in-route', async (request, reply) => {
      reply.status(500);
      throw new Error('500 error');
    });
  4. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Dec 9, 2025
  5. added
    External DependencyTo close this issue, an external dependency needs to be adjusted/fixed
    on Dec 12, 2025
  6. self-assigned this
    on Dec 18, 2025
  7. JPeer264 commented on Dec 18, 2025

    @JPeer264
    Member

    for the record. I'll leave this open until they released a new version including the fix. I'll then create some test cases in our repo to verify it will also work on our side reliably

  8. JPeer264 commented on Jan 19, 2026

    @JPeer264
    Member

    Please update to [email protected] to have this fixed

  9. added a commit that references this issue on Jan 19, 2026
    df0bff8
  10. github-actions commented on Jan 19, 2026

    @github-actions
    Contributor

    A PR closing this issue has just been released 🚀

    This issue was referenced by PR #18838, which was included in the 10.35.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

BugExternal DependencyTo close this issue, an external dependency needs to be adjusted/fixedNode.js

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions