In a production Next.js build, a Server Action invoked from a form throws an unexpected exception — a database call failed. What does the browser actually receive, where do you find the real error, and what does that imply about how the action should report an expected validation failure?

## What the client is given Split the behaviour by build. **In development**, an uncaught error inside a Server Action shows up with its real message and stack — in the overlay and in the terminal. Debugging feels normal. **In production**, the message and stack are withheld from the client on purpose. The browser receives a generic error object that carries a `digest` property: a hash identifying that specific error occurrence. The full error, with its message and stack, is emitted on the server, tagged with the same digest. Your job during an incident is to take the digest the user or your client-side error reporter captured and grep the server logs for it. ## Why redaction is the right default Errors thrown on the server carry server context. A failed query can echo the SQL and column names, a filesystem error carries absolute paths that reveal the deployment layout, a network error names an internal hostname or port, and an ORM's constraint violation can quote the offending value — which may itself be another user's data. Shipping those strings to a browser is a real information-disclosure path, and no team reliably audits every possible throw site for what it might reveal. Redacting by default and opting in per message is the only version of this that holds up. ## The design consequence Once you accept that a throw produces something the user cannot act on, the API design falls out. Distinguish two categories: **Expected outcomes.** The email is already registered. The password is too short. The document changed since you loaded it. The coupon expired. None of these are exceptions — they are results. `return` them, as a serializable object the UI can render: ```ts 'use server' export async function signUp(_prev: unknown, formData: FormData) { const email = String(formData.get('email') ?? '') if (!email.includes('@')) { return { ok: false, fieldErrors: { email: 'Enter a valid email address.' } } } // ... return { ok: true } } ``` The returned value comes back in the action's response and is available to render inline next to the field. It survives production untouched, because it is data you chose to send, not an error that was redacted. **Unexpected failures.** The database is unreachable, a dependency threw, an invariant broke. Let those throw. They become a redacted client-side error plus a full server log entry — exactly the right split, because the user can do nothing but retry and the operator needs the stack. A useful heuristic when reviewing an action: if you can write the sentence the user should read, the case belongs in a `return`. If you cannot, it belongs in a throw. ## Getting a message to the user without leaking When a caught internal failure does need user-visible text, write the text yourself rather than forwarding the caught error: ```ts try { await db.order.create({ data }) } catch (err) { console.error('order create failed', err) // full detail, server side return { ok: false, message: 'We could not place your order. Please try again.' } } ``` That gives the user a sentence, the operator a stack, and the attacker nothing. ## Operational hygiene - **Capture the digest client-side.** Whatever renders your failure state should record the digest into your error reporter; without it, correlation with server logs is guesswork. - **Do not re-throw a caught error just to "pass it along".** It is redacted all the same, and you have lost the chance to return something useful. - **Do not develop against the dev overlay only.** The failure UX you should be reviewing is the production one, which is much less informative than what you have been staring at. - **Check that server logs actually leave the machine.** The redaction model is only workable if the full error lands somewhere queryable in your hosting environment. ## Common misconception The frequent wrong answer is "catch the error in the action and return `err.message` so the user sees it". That reintroduces exactly the leak the redaction exists to prevent — now under your own code, where no framework can protect you — and it produces user-facing copy written by a database driver.