[Bug]: Modified ArrayBuffer exception when running Jest with SES enabled

Version

27.2.5

Steps to reproduce

1. Clone my repo at https://github.com/samsiegart/jest-ses-repro
2. yarn install
3. yarn test

Expected behavior

The test runs and passes.

Actual behavior

Test suite fails to run with:

 FAIL  ./sum.test.js
  ● Test suite failed to run

    Unexpected intrinsic intrinsics.ArrayBuffer.__proto__ at %FunctionPrototype%

Additional context

I am using SES in my application. Part of what SES does is freezes certain objects and types, like ArrayBuffer. It does this by invoking a lockdown function, which happens when doing import '@agoric/install-ses' in setupTests.js in my repo. It appears that Jest is modifying the ArrayBuffer constructor in some way, causing this to break, and I would like to figure out where and why, and hopefully fix it so that Jest is compatible with SES.

I have also tried running lockdown before Jest is loaded and executed, and I get a similar, but more opaque error:

TypeError: Cannot assign to read only property 'constructor' of object '[object Object]'

I believe this happens for the same reason. After ArrayBuffer is frozen, when Jest tries to modify the constructor, it throws an error.

Any pointers to where this modification could be happening, or how to get a more informative stack trace to appear, would be greatly appreciated.

Environment

npx: installed 1 in 0.652s

  System:
    OS: Linux 5.10 Ubuntu 20.04.3 LTS (Focal Fossa)
    CPU: (16) x64 AMD Ryzen 7 5800X 8-Core Processor
  Binaries:
    Node: 14.16.0 - ~/.nvm/versions/node/v14.16.0/bin/node
    Yarn: 1.22.11 - /usr/local/bin/yarn
    npm: 6.14.11 - ~/.nvm/versions/node/v14.16.0/bin/npm
  npmPackages:
    jest: ^27.2.5 => 27.2.5

[kriskowal]

This seems to be a symptom of Jest’s general approach to fixing instanceof when it blesses child VM contexts (Realms) with certain Node.js API’s from the main Node.js Realm (https://github.com/facebook/jest/blob/8c35c4d5581d0a27952851fb94723dc73842c97a/packages/jest-environment-node/src/index.ts#L42) as in response to https://github.com/facebook/jest/issues/3186

However, fixing “identity discontinuity hazards” in this fashion leads to whacking moles, if not forever, for a very long time. For example, I expect that calling fetch() and then response.json() in a the child realm results in instanceof checks for Object and Array failing in the test realm. Every time you fix one instanceof check by punching another intrinsic from the incubating realm down to the child realm, it creates a new failure for any methods of that object that return non-primitives. Here’s another: new TextEncoder().encodeInto(buffer) instanceof Object likely fails.

It might be worthwhile to consider using vm2 instead, which provides a full “membrane” between realms.

🙏 @mhofman for isolating the issues above.

[erights]

This is worth re-examining