Make Server Component Error Serialization Configurable (Expose Certain Errors to Client in Production

[tansut]

Goals

1. Allow developers to optionally expose certain error types (e.g. BusinessError, ValidationError) from Server Components or Server Actions to the client in production builds.
2. Enable more user-friendly error handling without compromising sensitive system-level errors.
3. Maintain the current secure default behavior while offering flexibility for business-specific use cases.

Background

Currently, in production builds, Next.js strips error messages and stack traces from Server Components (and Server Actions) and replaces them with a generic:

“An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details.”

While this behavior is great for security, it hinders real-world scenarios like:

• Displaying user-facing business validation messages (e.g. “Your invitation link has expired”)
• Gracefully handling known exceptions (e.g. “This report is not available for your subscription plan”)
• Logging actionable, business-level errors with context in client-side tools like Sentry/PostHog/Highlight

Today, developers must implement awkward workarounds — catching errors on the server, converting them to serialized responses, and rebuilding custom error rendering logic.

Proposal

Introduce a mechanism that allows certain error types to opt-in to client-side exposure in production builds.

experimental: {
  exposeBusinessErrors: true,
}

export class BusinessError extends Error {
  [Symbol.for('next.expose')]: true = true;
}

✅ Benefits
• Enables better user feedback on known errors (without losing security for unknown ones)
• Reduces boilerplate in Server Components and Actions
• Aligns with existing use cases in forms, authentication flows, and business logic
• Keeps current secure behavior as default (opt-in only)

[jrwpatterson]

I have just spent a day crafting nice errors and had to work around this problem. I definitely think this is something we should have so we don't need to propagate errors from through the application.

[Maciel64]

Full support!

This next approach makes no sense, in my opinion. I'm building a fullstack app, using services and repositories to achieve a well-defined and reusable architecture. A service should return data or stop the flow if there is an error. It doesn't make sense to return objects with `{ error: 'error message' } instead of throwing errors.

[Pnlvfx]

That's why I'm switching out of nextjs, they think we're idiot and they wanna do all on their code, as if we don't know what error we can expose on the client.

[zaramcei]

It really sucks. This useless error messages show on staging environment and it makes hard to debug even on staging environment.