Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

null-upgrade orch vats to get fixed liveslots #9978

Closed
warner opened this issue Aug 27, 2024 · 2 comments
Closed

null-upgrade orch vats to get fixed liveslots #9978

warner opened this issue Aug 27, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@warner
Copy link
Member

warner commented Aug 27, 2024

What is the Problem Being Solved?

I'm working on liveslots this week, to fix some GC bugs (#9939, #9956, #8756, #7355), where at least 9939 is critical to avoid vats making fatal syscalls and being killed by the kernel.

These bugs have been around for a year, but didn't really cause problems until we started using short-lived WeakMaps and weak Stores, because the vat-killing bug is only triggered when a weak collection is deleted. The @agoric/vows package uses short-lived weak stores and weakmaps extensively, and the new orchestration vats (deployed to mainnet in upgrade-16, 23-Jul-2024) use vows extensively. Nobody is using the orch vats yet, but if they did, there's a risk of the vats being killed, which would be a big mess.

The Task

So we need to fix those orch vats, by doing an upgrade which will let them start using the new liveslots, that includes the fixes for those bugs.

First, we need to get the PRs for those bugs landed (one is in review, I should submit the second today or tomorrow). We should make sure these changes make it into the "upgrade17" chain-halting upgrade, which will make the new version of liveslots available for all new vats, and all vat upgrades.

Then, we should prepare a core-eval which does a null-upgrade ("null" means same ZCF and contract code as before, but any upgrade will pull in the latest liveslots) of the orch vats:

  • v134-network, v135-ibc, v136-localchain, v137-transfer
  • (and maybe other vats, if they're prepared to be upgraded)

Those null-upgrades should be deployed as either:

  • 1: a "core-proposal" that executes as part of upgrade17
  • 2: a "core-eval" that activates some time after upgrade17 happens

So we're either doing everything as part of upgrade17, or we're doing it in two steps (upgrade17, then core-eval).

@warner warner added the enhancement New feature or request label Aug 27, 2024
@dckc
Copy link
Member

dckc commented Aug 29, 2024

Fixed in #9868 , I'm pretty sure:

bundleRefs: {
ibc: publishRef(install('@agoric/vats/src/vat-ibc.js')),
network: publishRef(install('@agoric/vats/src/vat-network.js')),
localchain: publishRef(install('@agoric/vats/src/vat-localchain.js')),
transfer: publishRef(install('@agoric/vats/src/vat-transfer.js')),
},

@aj-agoric
Copy link

Closing this issue pursuant to this conversation which determines further testing is not cost effective at this time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants