Skip to content

[Nuxt] Ability to customize/turn off Sentry's Nitro hook handler #15409

Closed
@brtinney

Description

@brtinney

Problem Statement

I want to be able to control the contexts that are being attached to the error (in particular, things about the request), but since there's no way to customize the handler that Sentry adds to hook into the nitro error event, I'm left in a bind. In particular, this causes me two issues:

  1. I cannot control the automatic filtering applied in the provided handler to exclude 4xx errors
  2. I cannot attach context from Nitro to the Sentry context -- doing this in beforeSend is not possible because even with the experimental asyncContext via useEvent(), the context will not be available in the sentry.server.config.ts file. However, it is fully available in the handler for the error hook.

Attempting to solely add a second handler that does everything I want runs into the issue of 5xx errors being captured by the Sentry handler, and my handler can't submit the error with the better context, as it gets dropped as a duplicate (not that receiving two errors is great, either).

Solution Brainstorm

I think there are some straightforward solutions, any of which I could make work to cover both of my concerns above:

  1. Add a property to the Nuxt module config that takes a function that will be used in place of the "default" Sentry-provided error hook handler
  2. Add a hook that we can use to modify the Sentry context, etc. before the rest of the hook handler runs. For example:
import type { CapturedErrorContext } from 'nitropack/runtime/types'
type HookResult = void | Promise<void>

export default defineNitroPlugin((nitroApp) => {
  nitroApp.hooks.hook('error', (error, context) => {
    nitroApp.hooks.callHook('sentry:error', error, context)
    // ...
  })
})

declare module 'nitropack' {
  interface NitroRuntimeHooks {
    'sentry:error': (error: Error, context: CapturedErrorContext) => HookResult
  }
}
  1. Add a flag to disable the included hook and leave it up to us to handle it (but keep the custom proxy handler, etc.)

The first or third solution is the most straightforward for me to get what I want -- I already have my own hook that does what I want. The second one has some downsides in that you can't actually drop the error via the custom hook, which is probably not great DX.

Metadata

Metadata

Assignees

Type

No type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions