Fastify 5 integration: `reply.statusCode` is always 200 in `shouldHandleError` , making docs example unusable
Is there an existing issue for this?
- [x] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- [x] I have reviewed the documentation https://docs.sentry.io/
- [x] I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases
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.
Hey thanks for the issue. It seems that this might be an issue in Fastify (https://github.com/fastify/fastify/issues/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');
});
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