feat(wave): report client-side load/render errors to Faro#1927
Open
efstajas wants to merge 1 commit into
Open
Conversation
SvelteKit catches errors thrown in load functions and during rendering, surfacing them to users as a full-page 500. Because they're caught, they never reach window.onerror / unhandledrejection — the only thing Faro's default web instrumentation observes — so these crashes were invisible in monitoring (e.g. a zod parse failure in a wave API response throwing inside an issue-page load). Add a client handleError hook that forwards these unexpected errors to Faro via a new guarded pushError helper, tagged with route, url and status. The helper no-ops when Faro isn't initialized (no monitoring consent, or PUBLIC_FARO_ENABLED off), so it's always safe to call.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds client-side crash reporting for SvelteKit load/render errors (which are normally swallowed before reaching window.onerror) by routing them through the app’s existing Grafana Faro integration, improving observability of user-facing “500” error screens in the Wave UI.
Changes:
- Introduces a client
handleErrorhook to forward unexpected client-side errors to Faro with route/url/status context. - Captures the initialized Faro instance in
faro-manager.tsand exposes a guardedpushError()helper.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/lib/utils/faro/faro-manager.ts | Stores the Faro instance and adds a safe helper to push exceptions when monitoring is enabled. |
| src/hooks.client.ts | Adds SvelteKit client handleError hook to report unexpected load/render crashes to Faro with route metadata. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
7
to
13
| export const init = () => { | ||
| const FARO_ENABLED = getOptionalEnvVar('PUBLIC_FARO_ENABLED', false, null); | ||
| const FARO_ENVIRONMENT = getOptionalEnvVar('PUBLIC_FARO_ENVIRONMENT', false, null); | ||
|
|
||
| if (FARO_ENABLED === 'true' && FARO_ENVIRONMENT) { | ||
| initializeFaro({ | ||
| faro = initializeFaro({ | ||
| url: 'https://faro-collector-prod-eu-west-2.grafana.net/collect/0a4519657ebc92ca47d9271be5503b63', |
Comment on lines
+16
to
+23
| export const handleError: HandleClientError = ({ error, event, status, message }) => { | ||
| const reported = error instanceof Error ? error : new Error(message); | ||
|
|
||
| pushError(reported, { | ||
| route: event.route.id ?? 'unknown', | ||
| url: event.url.pathname, | ||
| status: String(status), | ||
| }); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Users have reported seeing a full-page Error 500 ("Something went wrong on our end" 💀) when viewing an issue on the contributor dashboard — the screen
SingleIssueErrorrenders whenpage.status === 500.That status comes from an unexpected error thrown in a client-side
loadfunction (e.g. a zodschema.parsefailure inparseReswhen a wave API response doesn't match its DTO — the backend returns a clean200, so there's nothing in the backend logs). The frontend ships Grafana Faro, but none of these 500s show up in it: SvelteKit catches errors thrown inload/rendering, so they never reachwindow.onerror/unhandledrejection, which is all Faro's default web instrumentation observes. The result is a client-side observability blind spot — exactly the crashes users hit are the ones we can't see.Fix
src/hooks.client.tswith ahandleErrorhook. SvelteKit only calls this for unexpected errors (expectederror(...)throws like 404s are handled directly and never reach it), so everything that arrives is a genuine crash worth reporting. Each is forwarded to Faro tagged withroute,url, andstatus.faro-manager.tsand expose a guardedpushError(error, context)helper. It no-ops when Faro isn't initialized (user hasn't consented to monitoring, orPUBLIC_FARO_ENABLEDis off), so it's always safe to call.Notes
This only adds reporting — it doesn't change anything users see (SvelteKit's default error message is preserved). It doesn't fix the underlying issue-view 500; it makes that error (and any future client-side
load/render crash) visible in monitoring with its stack and route so the root cause can be diagnosed. Errors land in Loki asservice_name="app",kind="exception".Testing
npm run check— 0 errors.