[Flight] Serialize Error Values

[sebmarkbage]

The idea is that the RSC protocol is a superset of Structured Clone. #25687 One exception that we left out was serializing Error objects as values. We serialize "throws" or "rejections" as Error (regardless of their type) but not Error values.

This fixes that by serializing Error objects. We don't include digest in this case since we don't call onError and it's not really expected that you'd log it on the server with some way to look it up.

In general this is not super useful outside throws. Especially since we hide their values in prod. However, there is one case where it is quite useful. When you replay console logs in DEV you might often log an Error object within the scope of a Server Component. E.g. the default RSC error handling just console.error and error object.

Before this would just be an empty object due to our lax console log serialization:

After:

TODO for a follow up: Flight Reply direction. This direction doesn't actually serialize thrown errors because they always reject the serialization.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 30, 2024 6:51pm

[react-sizebot]

The size diff is too large to display in a single comment. The GitHub action for this pull request contains an artifact called 'sizebot-message.md' with the full message.

Generated by 🚫 dangerJS against 775defa

[eps1lon]

Does this also work for Actions that return error objects e.g. during form validation?

[sebmarkbage]

Yes. But not very useful since its message will be hidden in prod.

[sophiebits]

Will people write code that does that in dev and then be sad when it breaks in prod?

[eps1lon]

Will people write code that does that in dev and then be sad when it breaks in prod?

We got this feedback already for thrown errors from Server Actions. @gnoff mentioned that we always want to include a notice in the error message that it'll be stripped in prod to prevent relying on messages for prod behavior.

But we didn't follow-up. Might worth bringing this up again.