feat(node): Add shouldHandleError option to fastify error handler #13198
Conversation
AbhiPrasad
added
the
Integration: fastify
| const shouldHandleError = options?.shouldHandleError || defaultShouldHandleError; | ||
|
|
||
| fastify.addHook('onError', async (request, reply, error) => { |
There was a problem hiding this comment.
I think, since digging into this more, that my initial suggestion was incomplete - reply.status is probably going to be 200 here, and instead there is, I think, error.statusCode, according to the fastify-sentry plugin? https://github.com/immobiliare/fastify-sentry/blob/main/lib/base.js#L43-L46
There was a problem hiding this comment.
This is not a fastify-sentry plugin, but an immobiliare plugin for fastify. Not official.
Reply and Error are not the same since the reply could have been sent before the error occurred.
| * @param error Captured middleware error | ||
| */ | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| shouldHandleError?(this: void, request: any, reply: any, error: Error): boolean; |
There was a problem hiding this comment.
It is better to use explicit types instead of any
import type { FastifyRequest, FastifyReply } from 'fastify';
There was a problem hiding this comment.
for that we need to depend on the fastify package, which we cannot do in the generic node package.
There was a problem hiding this comment.
// grumbling-mod-on
When someone was too lazy to take the framework packages out of the general node package :) Although this was proposed for version 8
// grumbling-mod-off
Perhaps, a dummy interface can be used. After all, only a little piece of it is used.
Or the generic type.
There was a problem hiding this comment.
When someone was too lazy to take the framework packages out of the general node package :) Although this was proposed for version 8
It was a conscious decision not to do this.
Perhaps, a dummy interface can be used. After all, only a little piece of it is used.
Which is exactly as fragile as any, if not more, since it gives a false sense of security and disables all of the ts-eslint checking.
There was a problem hiding this comment.
I have to disagree with you. The any can completely disable checks, but the interface will force you as a developer to add/edit the necessary entry. This means that some commands will not be called accidentally. As below, when the statusCode may be undefined.
Anyway, this is just my opinion. However, the number of open issues with the new version 8 makes it clear that it is possible. In any case, it is your conscious decision.
There was a problem hiding this comment.
I think you're making wrong assumptions about how our linting works. When we define stuff as any, yes typescript will not check it anymore, however, eslint will still not let us access any fields without narrowing down and checking for their exact type first.
I encourage you to pull the repo and try it out.
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| function defaultShouldHandleError(_request: any, reply: any, _error: Error): boolean { | ||
| // eslint-disable-next-line @typescript-eslint/no-unsafe-member-access | ||
| return reply.statusCode >= 500; |
There was a problem hiding this comment.
statusCode can be undefined
There was a problem hiding this comment.
// eslint-disable-next-line is used everywhere, it is not clear why you need eslint in the project then.
There was a problem hiding this comment.
statusCode can be undefined
Could probably implement this similar to what's been done in the express integration.
|
@magnusburton Hi, there might be some communication issue since I'm not working on it. |
|
@AbhiPrasad thanks for taking this on! Is there anything I can do to help get this shipped? |
|
@lforst is there anything I can do to help get this merged? Thanks! |
|
I was just reminded by this PR - I had accidentally unsubscribed from it. Apologies about the delay, I'm pushing up changes now, let's get this to the finish line. Sorry about the trouble everyone - totally my fault! |
resolves #13197
Aligns fastify error handler with the express one.
shouldHandleErrorto allow users to configure if errors should be capturedshouldHandleErroronly captures errors for 5xx status codes.