Marshal fails to rehydrate errors in Chrome, Firefox, Safari

[kriskowal]

Describe the bug

Scene: a web page CapTP client connects over WebSocket to a remote CapTP endpoint. The client invokes a remote method. The server throws an error. The server logs that error. The client receives the error. However, instead of reporting an error with the same message as observed on the server, we see an error indicating that Marshal was unable to hydrate the error.

Chrome:

Error#2: Passable Error stack own property must be a data property: Object

Firefox:

Error#2: Passable Error has extra unpassed property fileName

Safari

Error#2:"Passable Error has extra unpassed property""line"

Steps to reproduce

To reproduce in the Endo repository:

In endo/packages/cli, create err.js

export const make = async powers => {
  await E(powers).bogus();
};

Then, also in endo/packages/cli:

bin/endo purge --force
bin/endo install err.js --name err --listen 3333 --powers NONE --open

This will open your system browser to a weblet. There will be one of the above errors in the JavaScript console.

Expected behavior

An error should be reported that has the same message as the error reported on the server.

For the isolated reproduction above, you can find the server’s error in one of the Endo worker logs. I apologize ahead of time that this is not yet polished: bin/endo log will show you the most recent daemon logs and the error should be in there. bin/endo where log will tell you where that log file is so you can open it elsewhere. bin/endo where state will show you where all the logs are.

Platform environment

Any system, any browser.

Additional context

Screenshots

[erights]

Reopening because the previous fix #2200 did not update regular non-browser tests so they would work on a platform with v8's problematic stack-accessor behavior. I accidentally discovered this when testing locally with Node 21, which our CI does not yet test.

[erights]

Root cause:

At https://chromium-review.googlesource.com/c/v8/v8/+/4459251 v8 changed their error stack property into an own accessor property with per-instance getters and setters.

[erights]

@kriskowal , @frazarshad , since this is in the same ballpark, I went ahead and co-assigned this to the three of us.

[erights]

https://issues.chromium.org/issues/40279506 is now public, so we can cite it.

[erights]

First reported at tc39/proposal-error-stacks#26 (comment)

[erights]

See also https://github.com/endojs/endo/blob/master/packages/ses/error-codes/SES_UNEXPECTED_ERROR_OWN_STACK_ACCESSOR.md

[michaelficarra]

@erights Since the own accessor used the same two powerful functions for get/set, couldn't you deny access to them through virtualising all built-ins that read the property descriptor and Reflect.get/Reflect.set? In the shim, you can just check if their identity matches the values of the get/set fields that would be returned.

[mhofman]

@erights Since the own accessor used the same two powerful functions for get/set, couldn't you deny access to them through virtualising all built-ins that read the property descriptor and Reflect.get/Reflect.set? In the shim, you can just check if their identity matches the values of the get/set fields that would be returned.

We tried and implemented that at some point, but it's really expensive!

[michaelficarra]

Given the choice between safe and fast...

[mhofman]

It's also really hard to get right. In our first implementation last year, I had found 2 flaws that would still have leaked the stack accessors. It also layered terribly. We have first run code that captures all original intrinsics for internal use. We do mark some of them as dangerous to make sure we can audit their usage. To avoid having to re-audit all the internal uses of these reflection methods, we had to "patch" them before being captured. All that for a single engine's misbehavior. Ultimately, we decided to tolerate the capability leak these accessors enable (proxies enable similar leaks), and instead fix whatever error objects we encounter with the accessors.