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

chore(pp-upgrade): test functionality after provisionPool and bank upgrade #10419

Merged
merged 4 commits into from
Dec 3, 2024

Conversation

anilhelvaci
Copy link
Collaborator

@anilhelvaci anilhelvaci commented Nov 7, 2024

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

Copy link

cloudflare-workers-and-pages bot commented Nov 7, 2024

Deploying agoric-sdk with  Cloudflare Pages  Cloudflare Pages

Latest commit: 164151e
Status: ✅  Deploy successful!
Preview URL: https://37bef8fc.agoric-sdk.pages.dev
Branch Preview URL: https://anil-10395-pp-vbank.agoric-sdk.pages.dev

View logs

@anilhelvaci anilhelvaci marked this pull request as ready for review November 7, 2024 08:33
@anilhelvaci anilhelvaci requested a review from a team as a code owner November 7, 2024 08:33
@anilhelvaci anilhelvaci changed the title chore(pp-upgrade): create and set a new bridgeHandler in the proposal chore(pp-upgrade): chore(pp-upgrade): test functionality after provisionPool and bank upgrade Nov 7, 2024
@Chris-Hibbert Chris-Hibbert added the force:integration Force integration tests to run on PR label Nov 7, 2024
Copy link
Contributor

@Chris-Hibbert Chris-Hibbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect that it would be a good idea to convert makeBridgeProvisionTool from a Far object to an Exo, but I'm not positive. I've asked for advice and will let you know what I hear.

golang/cosmos/app/upgrade.go Outdated Show resolved Hide resolved
@Chris-Hibbert
Copy link
Contributor

I suspect that it would be a good idea to convert makeBridgeProvisionTool from a Far object to an Exo, but I'm not positive. I've asked for advice and will let you know what I hear.

The response I got was "yes, convert it to an Exo", but it appears that this object may be one of those discussed in #8849, which may mean we need a clearer story on upgrading the bootstrap vat (V1) before we can proceed to upgrade provisionPool.

You can work on converting it to an Exo

I need to have more design discussions with the kernel team about the impact. The concern seems to be about whether auto-provisioning will continue to work. The links mentioned were

@anilhelvaci
Copy link
Collaborator Author

The response I got was "yes, convert it to an Exo", but it appears that this object may be one of those discussed in #8849, which may mean we need a clearer story on upgrading the bootstrap vat (V1) before we can proceed to upgrade provisionPool.

You can work on converting it to an Exo

I need to have more design discussions with the kernel team about the impact. The concern seems to be about whether auto-provisioning will continue to work. The links mentioned were

#10425 tracks this now. From your comment I understand the path for this PR to land;

  • Close 10425
  • wait the plan for upgrading vat-bootstrap is clear
  • address change requests

Could you please confirm? @Chris-Hibbert

@anilhelvaci anilhelvaci changed the title chore(pp-upgrade): chore(pp-upgrade): test functionality after provisionPool and bank upgrade chore(pp-upgrade): test functionality after provisionPool and bank upgrade Nov 11, 2024
@Chris-Hibbert
Copy link
Contributor

#10425 tracks this now. From your comment I understand the path for this PR to land;

  • Close 10425
  • wait the plan for upgrading vat-bootstrap is clear
  • address change requests

Could you please confirm?

Let's pursue 10425. If we can write tests that show the bootstrap vat doesn't break, and we can continue to provision new wallets, I don't think we have to be able to upgrade vat-bootstrap before upgrading provisionPool.

a3p-integration/proposals/p:upgrade-19/.gitignore Outdated Show resolved Hide resolved
golang/cosmos/app/upgrade.go Outdated Show resolved Hide resolved
packages/inter-protocol/src/provisionPoolKit.js Outdated Show resolved Hide resolved
packages/inter-protocol/src/provisionPoolKit.js Outdated Show resolved Hide resolved
packages/inter-protocol/src/provisionPoolKit.js Outdated Show resolved Hide resolved
@anilhelvaci anilhelvaci force-pushed the anil/10395-pp-vbank branch 2 times, most recently from d5f827a to 58e7583 Compare November 27, 2024 17:50
Copy link
Contributor

@Chris-Hibbert Chris-Hibbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I requested a few clean-ups, but this looks good. Thanks.

packages/inter-protocol/src/provisionPoolKit.js Outdated Show resolved Hide resolved
* @param {string} wanted
* @param {string} [from]
*/
export const bankSend = (addr, wanted, from = VALIDATORADDR) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please pull bankSend, provision, introduceAndProvision, getProvisionedAddress, and checkUserProvisioned out to a separate library file that can be shared. We shouldn't have to define these more than once.

Maybe getProvisionedAddress is simple enough that it doesn't have to go in the library.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please pull bankSend, provision, introduceAndProvision, getProvisionedAddress, and checkUserProvisioned out to a separate library file that can be shared. We shouldn't have to define these more than once.

#10514 already tracks this one. I can put those methods into a helper module then move them to the shared library as part of #10514. I think we shouldn't wait for the shared library to land this PR.

Copy link
Contributor

@Chris-Hibbert Chris-Hibbert Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we shouldn't wait for the shared library to land this PR

That's fine.

@anilhelvaci anilhelvaci force-pushed the anil/10395-pp-vbank branch 3 times, most recently from 6e7cda9 to 9c75709 Compare November 27, 2024 20:17
@anilhelvaci anilhelvaci force-pushed the anil/10395-pp-vbank branch 2 times, most recently from 6ae5628 to 7346df1 Compare November 27, 2024 21:43
@anilhelvaci
Copy link
Collaborator Author

We talked about commenting about upgrade-19 stuff in upgrade.go however the CI seems to be failing because it expects upgrade-paRegistry.js core eval to be executed:

registry › priceAuthorityRegistry upgrade

  registry.test.js:16

   15: test('priceAuthorityRegistry upgrade', async t => {
   16:   t.is(await getIncarnation('priceAuthority'), 1); 
   17:                                                    

  Difference (- actual, + expected):

  - 0
  + 1

I think the issue is related to this PR that recently landed #10418 @Chris-Hibbert

@Chris-Hibbert
Copy link
Contributor

however the CI seems to be failing because it expects upgrade-paRegistry.js core eval to be executed:

I ran into a similar issue. My conclusion was that the upgrades that are not in U18 should be cleanly moved to u19 and tested there. If that means you have to move some tests from U18 or correct some expected output in U18 in a3p-integration, then that's the right approach. Leaving those tests anachronistically in U18 in a3p-integration will be more confusing than cleaning it up.

@anilhelvaci
Copy link
Collaborator Author

I ran into a similar issue. My conclusion was that the upgrades that are not in U18 should be cleanly moved to u19 and tested there. If that means you have to move some tests from U18 or correct some expected output in U18 in a3p-integration, then that's the right approach. Leaving those tests anachronistically in U18 in a3p-integration will be more confusing than cleaning it up.

Yep, I think it's resolved in master.

I rebased my branch on top of the master. Could you please approve the PR if it looks good to you? @Chris-Hibbert

Copy link
Contributor

@Chris-Hibbert Chris-Hibbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -1,5 +1,8 @@
import { E } from '@endo/far';
import { deeplyFulfilled } from '@endo/marshal';
import { makeTracer } from '@agoric/internal';

const tracer = makeTracer('UpgradeProvisionPool');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not a big deal,but we usually call this trace.

@anilhelvaci anilhelvaci added the automerge:rebase Automatically rebase updates, then merge label Dec 3, 2024
Make sure the handler returned from E(creatorFacet).makeHandler() is durable and provisionPool is upgradable multiple times.

Refs: #10425
Refs: #10564

fix: remove unnecessary comment

chore: get rid of ephemera, address change requests

Refs: #10395
Refs: #10425

fix: drop trace

chore: address change requests

fix: rebase fixes

fix: yarn.lock fix

fix: bring back missing upgrade-paRegistry proposal
@mergify mergify bot merged commit dcf2772 into master Dec 3, 2024
79 checks passed
@mergify mergify bot deleted the anil/10395-pp-vbank branch December 3, 2024 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge:rebase Automatically rebase updates, then merge force:integration Force integration tests to run on PR
Projects
None yet
2 participants