Add a hook to observe server function errors before serialization#2192
Closed
adipascu wants to merge 1 commit into
Closed
Add a hook to observe server function errors before serialization#2192adipascu wants to merge 1 commit into
adipascu wants to merge 1 commit into
Conversation
✅ Deploy Preview for solid-start-landing-page ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
commit: |
5629754 to
8a09b9d
Compare
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
When a server function throws, the handler in
packages/start/src/fns/handler.tscatches the error, setsX-Error, and serializes it into the response for the calling client. No server-side error hook ever fires, so genuine crashes inside server functions are invisible to monitoring (Sentry and friends): the platform error hooks (for example Nitro'serrorhook) only see errors that escape the handler, and these never do.The result is that a production server function can crash on every call while dashboards stay green, and the only signal is users reporting a generic failure state.
Prior art in other frameworks
handleError, called only for unexpected errors (expectederror()throws skip it), letting apps report to monitoring and return a sanitized user-safe representation. This expected-vs-unexpected split is exactly what server-function consumers need here too.onRequestErrorininstrumentation.ts, invoked for server errors including Server Actions (routeType: 'action'), designed for custom observability providers.registerGlobalMiddleware, which wraps every server function and can observe failures.Proposal
Call an app-registered global hook from the handler's
catch, before serialization, skipping thrownResponses since those are control flow (redirects, forbidden):An app can then register
globalThis.__reportServerFnErrorfrom its server entry (or a Nitro plugin) and forward to its monitoring SDK.Status
Draft on purpose: the global hook is the minimal shape that solves the problem, and I am happy to rework it into whatever API surface you prefer (an option on the handler, an exported
setServerFnErrorHandler, an event on the app instance, or a SvelteKit-stylehandleErrorin the server entry). We currently maintain this as apnpm patchin production alongside #2159 and would love to drop both.