Repository navigation
Export @sentry/vue errorHandler #11471
Description
Problem Statement
I'm trying to write an ErrorBoundary component to scope components to the right vue app in our nested-vue-app microfrontends setup in order to capture them with specific tags to make our multiplexed transport route them correctly (as described on https://docs.sentry.io/platforms/javascript/guides/vue/best-practices/micro-frontends/#manually-route-errors-to-different-projects)
I have a component looking like this where I'd like to add some tags to the scope, then have it processed with Sentry's error handler, without having it propagate higher up to other ErrorBoundaries
import { type SlotsType, defineComponent, onErrorCaptured } from 'vue'
import { withScope, captureException } from '@sentry/vue'
/**
* This is a transparent component that captures errors propagating from
* descendant components and captures it with sentry with extra information
* about the microfrontend to ensure it's routed to the correct sentry project.
*
* It renders the default slot with props passed through transparently.
*/
export default defineComponent({
name: 'ErrorBoundary',
slots: Object as SlotsType<{ default: Record<string, unknown> }>,
setup (props, { slots, attrs }) {
onErrorCaptured((err, vm, info) => {
withScope(scope => {
scope.setTag('appName', `${__APP_NAME__}`)
scope.setExtra('vueInfo', info)
// TODO: Here I'd like to "forward" the error to sentry's own error handler to get it further formatted right and captured with the right hints etc. and logged with sentry's logErrors logger
captureException(err)
})
return false
})
return () => slots.default(props)
}
})Solution Brainstorm
Either, it'd be nice to export https://github.com/getsentry/sentry-javascript/blob/develop/packages/vue/src/errorhandler.ts#L12-L56 so you can create a "custom" instance of that error handler
Alternatively, is there maybe a way to set these tags at the current scope when it gets to the error handler, keep propagating it, and skip setting those tags if they're already set at higher error boundary functions?
The documentation recommends against it, but could something like this work perhaps?
onErrorCaptured((_err, vm, info) => {
const pCtx = getCurrentScope().getPropagationContext() as PropagationContext & { mfTagged?: boolean }
if (pCtx.mfTagged) return true
setTag('appName', `${__APP_NAME__}`)
getCurrentScope().setPropagationContext({
...pCtx,
mfTagged: true
} as unknown as PropagationContext)
return true
})Metadata
Metadata
Assignees
Projects
- StatusShow more project fieldsNo status
Activity
swantzter commentedon Apr 8, 2024
Well upon further testing, the second solution that lets the event propogate doesn't work - it seemingly attaches to the top level scope (which, I guess I expected) and thus locks all future errors to that appName
swantzter commentedon Apr 8, 2024
To be able to ship as we need error reporting yesterday I've ended up vendoring a modified version of https://github.com/getsentry/sentry-javascript/blob/develop/packages/vue/src/errorhandler.ts#L12-L56
Using an ErrorBoundary.vue component looking like this
And sentry.ts looking like this
the main change to the latter is that I hardcoded our settings, and added a
withScope()around thecaptureException()call in thesetTimeout()to be able to tag the scope with the appName, which I'm also passing in as an extra param to the error handlerLms24 commentedon Apr 10, 2024
Hey @swantzter apologies for the late reply!
Are you fine with the custom code you wrote for this or do you still need a specific export from the SDK? We could generally think about exporting the errorHandler but we're a bit swamped with tasks at the moment, so I'm just trying to prioritize.
As for the ask around the scopes and propagation context: I believe I answered this (at least partially) here. Short version: There's very little we can do to retain scope integrity for MFE setups globally as long as there is no async context handling strategy for browsers.
swantzter commentedon Apr 11, 2024
@Lms24 no worries. The custom code route I went with works well for now, but it feels a little risky to keep in sync in case you change the error handler upstream.
So I wouldn't say this should be top priority, but I do think somewhere down the line this would still be very useful, and ideally a way to hook into it to add to the scope before the captureException
Lms24 commentedon Sep 28, 2026
I am going to close this because the issue has been stale for >2 years. If anyone still would like to get an export of our errorHandler, or an API as proposed in #24586, please feel free to tag me so that we can reopen.