test of restarting all vats #8158
Labels
Milestone
Comments
turadg
added
enhancement
This was referenced Nov 1, 2024
This was referenced Nov 6, 2024
mergify bot
added a commit
that referenced
this issue
Dec 3, 2024
…grade (#10419) closes: #10395 closes: #10425 closes: #10564 ## Description As mentioned in #8158, we need the ability to restart or replace all vats. This PR focuses on the vats v28-provisionPool and v14-bank. The goal is to make sure after upgrading both of those vats, v28-provisionPool functionality keeps working. We pay special attention to #8722 and #8724 during the tests as those issues were identified as potential problems against v28-provisionPool upgrade. ### Security Considerations v28-provisionPool and v14-bank are critical vats for the system when it comes to onboarding new users and keeping track of ERTP representations of user assets. Reviewers, please highlight the slightest risk you see. ### Scaling Considerations v28-provisionPool vat has a linear relationship with the number of users entering the Agoric system. So it is pretty important it keeps working. Reviewers, please highlight the slightest risk you see. ### Documentation Considerations None. ### Testing Considerations During the testing, we focused on `provisionPoolAddress`' cosmos level balances as our source of truth. The reasoning behind this is; if the IST balance of the `provisionPoolAddress` it can only mean - it has received the anchor asset we've sent - v28-provisionPool is notified of this balance change - executed a swap against corresponding PSM - deposited the payout to IST purse - v14-bank updated the balances correctly In our test we send two anchor assets; * USDC_axl to make sure v28-provisionPool recovered existing purses * USD_LEMONS to make sure v28-provisionPool is notified of new assets ### Upgrade Considerations Both v28-provisionPool and v14-bank are staged upgrades in `upgrade.go`
mergify bot
added a commit
that referenced
this issue
Dec 9, 2024
#10616) closes: #10408 ## Description As stated in #8158, we need to be able to upgrade any vat we want and make sure the system keeps working. This PR focuses on upgrading `vat-agoricNames`. ### Security Considerations I consider `vat-agoricNames` as a critical vat as it's the source trust for object identities. So it's crucial it keeps working after the upgrade. It's important to point out that if there were any keywords reserved before the upgrade, they will be lost after the upgrade as the reservations stored in ephemera. If this is important, we might consider re-reserving in the core eval. ### Scaling Considerations None. ### Documentation Considerations Don't think it's necessary as the functionality of `nameHub` is left untouched. ### Testing Considerations If we decide to re-reserve some keywords, we will need to add a test that verifies the core eval has indeed reserved those keywords. Please see below for the test plan I followed: https://github.com/Agoric/agoric-sdk/blob/1e4bebac1e3ee6df48dbe58e3e5bdf0e9e37cca2/a3p-integration/proposals/p%3Aupgrade-19/agoricNames.test.js#L3-L46 #### EDIT 2195ace removes ` write-chain-info.js` from `f:fast-usdc`. So we simulate what is does (relative to `agoricNames`) in order to test ephemeral `onUpdate` callbacks keep working after an `agoricNames` upgrade. ### Upgrade Considerations This PR itself upgrade `vat-agoricNames` and comes with a3p tests to verify the upgrade goes through and `agoricNames` keep working.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
We need to know that as an emergency measure we could force all the running vats to an upgraded environment. To know that works we need a test of restarting all vats after each upgrade.
Without this we risk a repeat of the breaking change in #8045 (known to be a breaking change to consumer of the package, but not the installed contracts)
Description of the Design
A new test like “launch a container with the chosen upgrade, apply the proposals we want to test”.
It needs a sandbox to test "what if we restarted all vats" without affecting the test's upgrade history.
It can use
restart-vats-proposal.jsmade for bootstrap tests. Note that that one also restarts "bootstrap vat" which is not designed to be restarted (#8849). It also skips over some other vats that had other tests in CI but that for the requirement above would still need to be restarted.Security Considerations
Scaling Considerations
Test Plan
Apply test retroactively to a breaking change such as that in #8045, perhaps by reverting #8146
Upgrade Considerations
The text was updated successfully, but these errors were encountered: