fix(vow): report unhandled vow rejections on collection or upgrade

[michaelfig]

closes: #10576

Description

This PR uses the design given in #10576 as a guideline. Some adaptations were made, such as needing to touch the vow states at different places and not sinking the ephemeral promise rejections.

Security Considerations

None expected, as the design does not introduce new facilities than have already been available.

Scaling Considerations

More bookkeeping data structures, but only linearly with the number of pending rejected vows.

Documentation Considerations

n/a

Testing Considerations

Testing unhandled rejections under AVA is impossible without causing AVA to report them as failures. The compromise made in this PR is not to test unhandled rejections by default, instead only if running the tests with yarn test:rejection.

Upgrade Considerations

The test suite contains a simple VatData upgrade test to verify basic unhandled vow rejections.

[cloudflare-workers-and-pages]

Deploying agoric-sdk with    Cloudflare Pages

Latest commit:	c20b271
Status:	✅  Deploy successful!
Preview URL:	https://0697ea21.agoric-sdk.pages.dev
Branch Preview URL:	https://mfig-unhandled-vow-rejection.agoric-sdk.pages.dev

View logs

[michaelfig]

@mhofman, I'd be interested in hearing what you think about patching AVA to honour a package.json option and/or command-line flag that exits with a 0 status code even if there were unhandled rejections?

It's not hard to find the relevant code by searching node_modules/ava for unhandledRejections, so I could probably cook up a patch for this once we decide on the appropriate behaviour.

[turadg]

patching AVA to honour a package.json option and/or command-line flag that exits with a 0 status code even if there were unhandled rejections?

I'll offer an opinion: patches are hard to maintain and should be a last resort. The stock Ava can spawn a worker thread or process as suggested here.

[dckc]

before closing #10576 , re upgrade considerations: are there any vats deployed with the previous vow package? Do we plan to upgrade them?

Also please consider how to verify this fix in a testnet.

For example, an a3p test could have an onFulfilled handler that throws.

Or... perhaps that's not cost-effective? Perhaps unit testing suffices?

[michaelfig]

I'll offer an opinion: patches are hard to maintain and should be a last resort.

I agree that our AVA patch has become unwieldy. However, the change I decided to make affects three lines.

The stock Ava can spawn a worker thread or process as suggested here.

The costs of working around stock AVA's stubbornness are far greater and involve much more code and conceptual overhead than patching AVA to be more flexible.

[michaelfig]

before closing #10576 , re upgrade considerations: are there any vats deployed with the previous vow package? Do we plan to upgrade them?

Vats using vows are:

ibc
localchain
network
orchestration
smart-wallet
transfer
zoe

I don't expect we'd actually upgrade them until u20, when we're targeting Upgrade All Vats.

Also please consider how to verify this fix in a testnet.
Or... perhaps that's not cost-effective? Perhaps unit testing suffices?

I agree it is worth at least an a3p test, which would serve as a canary if we ever unexpectedly broke the resumability of vows. I'll work on that.