DX flaw: An error occurred in the Server Components render

[elie222]

There's a major flaw in how errors for server actions are handled. They work differently in dev and in prod.

In dev: throwing an error in a server action exposes the error that occurred.
In prod: the message isn't exposed to the client. Instead you see: "An error occurred in the Server Components render"

The Next.js team's reasoning for this design choice is to make it easier for devs to see errors when working on their app.
The problem is that it actually makes it harder, because you only notice errors come up when running in production, and not immediately in development.

This has happened to my users. This has happened to me as a user on other sites too. Even well funded dev teams are making this mistake.

The fix:
Make prod and dev consistent. Or at the very least, add a message to the start of the error message that is exposed to the client that this will only show in dev. eg. "This only shows in Next.js development. You should not use this field in production. Error: ..."

[elie222]

What this bad DX causes on different sites:

The fix for anyone else reading this is to return {error: "my error"} to the client instead. Throwing the error to the client won't work. But we shouldn't be tripping people up like this to begin with.

[elie222]

It's even confusing in the Next.js tutorials:
https://nextjs.org/learn/dashboard-app/error-handling

"Seeing these errors are helpful while developing as you can catch any potential problems early."

They are not helpful because now devs don't realise the error message they think they're throwing won't displayed in production. But will only work for them while developing.

[elie222]

Potential solution:
#49426 (reply in thread)

[ADTC]

Thank you for the mention.

My current workaround (not solution) is, when I need to communicate errors from server to client, I return a "success result" in the Server Action which has the error details and a special keyword. Before processing this "success result" in client, I check whether it's actually an error disguised as success, then throw a real error instead. Then the catch block handles the error as normal.

I boiler-plated this in my project. (I hate having to boilerplate, but this was the most succinct way I could think of.) Every user-triggered call to a Server Action would have to have a client-side special then handler before the normal then handler. The special then handler (a reusable one) checks for the disguised error and throws it if it exists, or returns the success result if it doesn't. If thrown, the catch handler catches it and processes it as if it's a regular error. If the success result was returned, it gets passed into the normal then handler.

myServerAction()
  .then(checkForDisguisedError)
  .then(result => { /* process the result */ })
  .catch(error => { /* handle the error */ })

If you have to await on the result, you do it like this:

try {
  const result = await myServerAction().then(checkForDisguisedError)
  // process the result
} catch (error) {
  // handle the error
}

And the function (in TS, the <T> ensures the type of incoming result is the type of outgoing result as well):

export const checkForDisguisedError = <T>(result: T): T => {
  if ((result as any)?.error === 'special-keyword') {
    throw new Error( /* construct a normal error as you need */ )
  } else {
    return result
  }
}

[elie222]

I did a video on this issue, and show how I handle it too: https://www.youtube.com/watch?v=P8bwm6EUeZw