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

xr0master · 2024-09-09T06:17:43Z

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

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

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

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.

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.

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.

tmcw · 2024-08-05T18:40:22Z

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

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.

xr0master · 2024-09-09T06:28:53Z

statusCode can be undefined

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

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

xr0master · 2024-09-09T06:17:43Z

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

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

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

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.

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.

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.

tmcw · 2024-08-05T18:40:22Z

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

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.

xr0master · 2024-09-09T06:28:53Z

statusCode can be undefined

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

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

xr0master · 2024-09-09T06:17:43Z

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

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

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

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.

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.

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.

tmcw · 2024-08-05T18:40:22Z

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

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.

xr0master · 2024-09-09T06:28:53Z

statusCode can be undefined

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

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

xr0master · 2024-09-09T06:17:43Z

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

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

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

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.

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.

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.

tmcw · 2024-08-05T18:40:22Z

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

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.

xr0master · 2024-09-09T06:28:53Z

statusCode can be undefined

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

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

xr0master · 2024-09-09T06:17:43Z

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

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

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

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.

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.

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.

tmcw · 2024-08-05T18:40:22Z

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

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.

xr0master · 2024-09-09T06:28:53Z

statusCode can be undefined

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

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

xr0master · 2024-09-09T06:17:43Z

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

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

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

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.

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.

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.

tmcw · 2024-08-05T18:40:22Z

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

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.

xr0master · 2024-09-09T06:28:53Z

statusCode can be undefined

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

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

xr0master · 2024-09-09T06:17:43Z

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

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

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

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.

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.

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.

tmcw · 2024-08-05T18:40:22Z

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

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.

xr0master · 2024-09-09T06:28:53Z

statusCode can be undefined

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

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

xr0master · 2024-09-09T06:17:43Z

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

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

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

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.

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.

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.

tmcw · 2024-08-05T18:40:22Z

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

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.

xr0master · 2024-09-09T06:28:53Z

statusCode can be undefined

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

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

-Original file 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;
+}
 /**
  * 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) => {
+ 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 DownExpand 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;
+}

-Original file 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;
+}
 /**
  * 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) => {
+ 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 DownExpand 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;
+}

-Original file 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;
+}
 /**
  * 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) => {
+ 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 DownExpand 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;
+}

-Original file 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;
+}
 /**
  * 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) => {
+ 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 DownExpand 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;
+}

-Original file 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;
+}
 /**
  * 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) => {
+ 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 DownExpand 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;
+}

Uh oh!

Uh oh!

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

Uh oh!

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

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

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

Uh oh!

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

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

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

Uh oh!

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

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!