RFC: Do not sanitize error messages with Unexpected Server Error on the client if the error class has a property skipReactRouterSanitize: true

[remorses]

Right now all server error messages are sanitized here:

react-router/packages/react-router/lib/server-runtime/errors.ts

Line 48 in b4c3d7c

export function sanitizeError<T = unknown>(error: T, serverMode: ServerMode) {

I would like to preserve some error messages so that the message can be used in the client. This can be done with custom Error classes with a field skipReactRouterSanitize

class KnownError extends Error {
   skipReactRouterSanitize = true
}

[r52j]

+1

RSCs will be the future, but (as far as I understand) they currently lack a way to signal error details/context to the next error boundary:

• Error boundaries are always client-side, so any thrown exceptions are masked on the way.
• The throw data()/isRouteErrorResponse() way used in loaders/actions is no longer available.

We will need a solution for this issue before RSC will be stable. The proposal would be one way.

[sergiodxa]

Requiring a class property will mean you need to create custom error classes for errors you may not want to sanitize

I think it would be better to have an (optional) export on entry.server that receives the error, and other context, and returns a boolean if it should be sanitized or not

And by default this can be true on prod and false on dev

[r52j]

Or to be even more flexible, this function could return the error object to be forwarded to the client or undefined for the default sanitized error. This would allow for more control over what is exposed to the client, for example by mapping errors to ones that are more specific than the default sanitized error while still hiding the internals of the original error.

Another question would be what to do about the stack traces, which are something I would never want to be forwarded to the client in production.