Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(node): Add shouldHandleError option to fastify error handler #13198

Closed
wants to merge 2 commits into from
Closed

feat(node): Add shouldHandleError option to fastify error handler #13198

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0459800
feat(node): Add shouldHandleError option to fastify error handler
AbhiPrasad Aug 2, 2024
6e4ee13
Merge branch 'develop' into abhi-fix-fastify-errors
AbhiPrasad Aug 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 23 additions & 3 deletions packages/node/src/integrations/tracing/fastify.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,14 +61,27 @@ const _fastifyIntegration = (() => {
*/
export const fastifyIntegration = defineIntegration(_fastifyIntegration);

interface FastifyHandlerOptions {
/**
* Callback method deciding whether error should be captured and sent to Sentry
* @param error Captured middleware error
*/
// eslint-disable-next-line @typescript-eslint/no-explicit-any
shouldHandleError?(this: void, request: any, reply: any, error: Error): boolean;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is better to use explicit types instead of any
import type { FastifyRequest, FastifyReply } from 'fastify';

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for that we need to depend on the fastify package, which we cannot do in the generic node package.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// 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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}

/**
* Setup an error handler for Fastify.
*/
export function setupFastifyErrorHandler(fastify: Fastify): void {
export function setupFastifyErrorHandler(fastify: Fastify, options?: FastifyHandlerOptions): void {
const plugin = Object.assign(
function (fastify: Fastify, _options: unknown, done: () => void): void {
fastify.addHook('onError', async (_request, _reply, error) => {
captureException(error);
const shouldHandleError = options?.shouldHandleError || defaultShouldHandleError;

fastify.addHook('onError', async (request, reply, error) => {
Comment on lines +79 to +81
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

if (shouldHandleError(request, reply, error)) {
captureException(error, { mechanism: { type: 'middleware', handled: false } });
}
});

// registering `onRequest` hook here instead of using Otel `onRequest` callback b/c `onRequest` hook
Expand Down Expand Up @@ -131,3 +144,10 @@ function addFastifySpanAttributes(span: Span): void {
span.updateName(name.replace(/^fastify -> /, ''));
}
}

/** Returns true if response code is internal server error */
// 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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

statusCode can be undefined

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// eslint-disable-next-line is used everywhere, it is not clear why you need eslint in the project then.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

statusCode can be undefined

Could probably implement this similar to what's been done in the express integration.

}
Loading