Error objects lost during serialization

[emileber]

Context

When using @remote-ui/rpc or any package using it, built-in error objects are serialized as {}, which is unhelpful as any relevant information about errors happening in any function on the other side (iframe, web worker, etc) is lost when it reaches the host.

Hypothesis

Since built-in error object keys aren't enumerable, when an error instance gets serialized, it detects no keys and gets serialized as {}.

When looking at the @remote-ui/rpc package's code, it seems to confirm my assumption:

      if (isBasicObject(value)) {
        seen.set(value, [undefined]);

        const transferables: Transferable[] = [];
        const result = Object.keys(value).reduce((object, key) => {

Possible solutions

According to MDN's page on Error:

Error is a serializable object, so it can be cloned with structuredClone() or copied between Workers using postMessage().

What if we included a new case where we could treat instanceof Error as if it was a primitive to be transferred as-is?

Or would it make sense to switch to Object.getOwnPropertyNames() instead of Object.keys to get non-enumerable string properties as well?

Object.keys(error)
// => []
Object.getOwnPropertyNames(error)
// => ['stack', 'message']

[emileber]

For visibility and feedback: @lemonmade @robin-drexler @kencwng

[lemonmade]

I'd be in favor of special-casing Error instances, although it does seem odd to return an error instead of throwing it (which is already handled, for functions proxied via @remote-ui/rpc).

[emileber]

Good point, I didn't notice that errors were properly handled when thrown and just not serialized when passed around. In my specific case, I could probably get around this by changing our implementation to throw instead.

Though serializing error objects shouldn't hurt, right?

[emileber]

Reference for me:

• rethrow errors to allow global error collection #173

[emileber]

PR #255 might have helped or even fix this, I need to test again to see.