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

test(a3p-integration): update to agoric-upgrade-18 #10839

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

mujahidkay
Copy link
Member

@mujahidkay mujahidkay commented Jan 13, 2025

Agoric/agoric-3-proposals#211

Description

This PR updates a3p to use upgrade-18 image as well as remove u18 core proposals from upgrade.go. Also update multichain-testing yarn.lock file with peer deps (currently broken in master)

Security Considerations

None

Scaling Considerations

None

Documentation Considerations

None

Testing Considerations

All testing as it updates the base image for a3p

Upgrade Considerations

Removes u18 core proposals from upgrade.go

Copy link

cloudflare-workers-and-pages bot commented Jan 13, 2025

Deploying agoric-sdk with  Cloudflare Pages  Cloudflare Pages

Latest commit: f25b968
Status: ✅  Deploy successful!
Preview URL: https://b9768271.agoric-sdk.pages.dev
Branch Preview URL: https://mk-revise-a3p-post-u18.agoric-sdk.pages.dev

View logs

@Chris-Hibbert
Copy link
Contributor

Please retain verifyPushPrice, which is called in priceFeedUpdate.

@mujahidkay mujahidkay force-pushed the mk/revise-a3p-post-u18 branch from b436c99 to 12e62c8 Compare January 22, 2025 09:57
@mujahidkay mujahidkay self-assigned this Jan 22, 2025
@mujahidkay mujahidkay added the force:integration Force integration tests to run on PR label Jan 22, 2025
@mujahidkay mujahidkay force-pushed the mk/revise-a3p-post-u18 branch 2 times, most recently from 84f9b5c to 71a0889 Compare January 23, 2025 17:54
@turadg turadg force-pushed the mk/revise-a3p-post-u18 branch 3 times, most recently from c3f4254 to 1d15d42 Compare January 24, 2025 23:06
@mujahidkay mujahidkay force-pushed the mk/revise-a3p-post-u18 branch 2 times, most recently from d03f2cc to 8260dd4 Compare January 27, 2025 12:00
@mujahidkay mujahidkay marked this pull request as ready for review January 27, 2025 13:51
@mujahidkay mujahidkay requested a review from a team as a code owner January 27, 2025 13:51
cat accept.json
yarn agoric wallet send --offer accept.json --from agoric1ee9hr0jyrxhy999y755mp862ljgycmwyp4pl7q --keyring-backend test
ACCEPT_OFFER_ID=$(agoric wallet extract-id --offer accept.json)
# UNTIL https://github.com/Agoric/agoric-sdk/issues/10891
# ACCEPT_OFFER_ID=$(agoric wallet extract-id --offer accept.json)
Copy link
Member Author

Choose a reason for hiding this comment

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

Even though the fix is merged, reverting this to its original state still fails in CI. So, keeping the workaround for now.

@mujahidkay mujahidkay changed the title WIP draft to adopt u18 a3p changes test(a3p-integration): update to agoric-upgrade-18 Jan 27, 2025
@mujahidkay mujahidkay requested review from turadg and dckc January 27, 2025 15:52
Copy link
Member

@turadg turadg left a comment

Choose a reason for hiding this comment

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

Safe to merge. I think we need @Chris-Hibbert to confirm the test removals are appropriate.

Copy link
Member

@mhofman mhofman left a comment

Choose a reason for hiding this comment

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

I don't think the u19 proposals are being applied in the next chain software upgrade, upgrade.go needs some staged but commented changes to be uncommented. I'm confused as to how test would pass without this.

I'm also surprised to see so many pre-built submission checked-in for upgrade-next, but that seemed to have been there before and just carried from the previous upgrade-19, so out of scope for this PR.

CoreProposalSteps = append(CoreProposalSteps,
vm.CoreProposalStepForModules(
"@agoric/builders/scripts/vats/upgrade-orchestration.js",
),
)

// CoreProposals for Upgrade 19. These should not be introduced
Copy link
Member

Choose a reason for hiding this comment

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

I believe the following needs to be uncommented

Comment on lines -4 to -16
"sdk-generate": [
"testing/replace-feeDistributor-short.js replaceFeeDistributor",
"testing/add-USD-LEMONS.js addUsdLemons",
"vats/upgrade-provisionPool.js upgradeProvisionPool",
"vats/upgrade-asset-reserve.js upgradeAssetReserve",
"vats/upgrade-psm.js upgradePSM",
"vats/upgrade-paRegistry.js",
"vats/upgrade-agoricNames.js agoricNamesCoreEvals/upgradeAgoricNames",
"testing/add-USD-OLIVES.js agoricNamesCoreEvals/addUsdOlives",
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo",
"vats/upgrade-mintHolder.js upgrade-mintHolder A3P_INTEGRATION",
"vats/terminate-governor-instance.js terminate-governor board02963:ATOM-USD_price_feed"
]
Copy link
Member

Choose a reason for hiding this comment

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

I think some of these need to be moved to upgrade-next as they're used in test. Not sure how it might be passing without it.

Copy link
Member Author

Choose a reason for hiding this comment

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

They are present in n:upgrade-next/package.json

Copy link
Member

Choose a reason for hiding this comment

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

Oh I missed that. Ok we need to remove the ones now applies in upgrade.go from that list, and also probably any code that triggered the core eval submissions.

yarn ava initial.test.js

# test more, in ways that change system state
yarn ava ./*.test.js
Copy link
Member

Choose a reason for hiding this comment

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

I'm a little uncomfortable carrying the non-wildcard test approach of the previous upgrade-19. @Chris-Hibbert are there any interdependency of tests?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't believe so. I'd also prefer switching to a wildcard invocation.

multichain-testing/yarn.lock Outdated Show resolved Hide resolved
@@ -8,16 +8,9 @@
},
"type": "Software Upgrade Proposal",
"sdk-generate": [
"testing/replace-feeDistributor-short.js replaceFeeDistributor",
Copy link
Member

Choose a reason for hiding this comment

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

I think this one needs to remain

Copy link
Member Author

@mujahidkay mujahidkay Jan 27, 2025

Choose a reason for hiding this comment

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

But it is a part of core proposals? I would love to know why this should remain

Copy link
Member

Choose a reason for hiding this comment

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

I assumed that any testing proposal is solely used for testing. @Chris-Hibbert can you clarify?

// )
// }
func upgradeMintHolderCoreProposal(upgradeName string) (vm.CoreProposalStep, error) {
variant := getVariantFromUpgradeName(upgradeName)
Copy link
Member

Choose a reason for hiding this comment

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

Yikes, another variant type upgrade

Copy link
Member Author

Choose a reason for hiding this comment

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

:(

Copy link
Member

Choose a reason for hiding this comment

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

An eval.sh wouldn't be executed in chain software upgrade proposal. It should be deleted, and any core evals submitted should be tests related ones and moved to test.sh

Copy link
Member

Choose a reason for hiding this comment

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

Actually it looks like that based on sdk-generate some of these core evals were never actually submitted !? @Chris-Hibbert ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like you're right. I don't see tests for ZCF, or PriceAdminRegistry.

"testing/add-USD-LEMONS.js addUsdLemons",
"vats/upgrade-provisionPool.js upgradeProvisionPool",
"vats/upgrade-asset-reserve.js upgradeAssetReserve",
"vats/upgrade-psm.js upgradePSM",
Copy link
Member Author

Choose a reason for hiding this comment

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

Removing this results in the following error:

  ✔ verify trading after upgrade (12.7s)
  ─

  upgrade PSMs

  Rejected promise returned by test. Reason:

  Error {
    code: 'ENOENT',
    errno: -2,
    path: 'upgradePSM',
    syscall: 'scandir',
    message: 'ENOENT: no such file or directory, scandir \'upgradePSM\'',
  }

Probably because the test expects it to be a core eval (or am i doing something wrong)

test.serial('upgrade PSMs', async t => {
  // @ts-expect-error casting
  const { vstorageKit } = t.context;

  await evalBundles(UPGRADE_PSM_DIR);

Copy link
Member

Choose a reason for hiding this comment

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

I think you're right. Some core proposals were submitted in the test layer, which is incorrect because acceptance tests would have run against an non upgraded psm in this case. We need to remove this core eval from the test as it should now be done in the upgrade.go

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.

The test removals look correct.

Comment on lines 262 to 263
// Upgrade to include a cleanup from https://github.com/Agoric/agoric-sdk/pull/10319
"@agoric/builders/scripts/smart-wallet/build-wallet-factory2-upgrade.js",
Copy link
Contributor

Choose a reason for hiding this comment

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

Please reinstate. #10794 wants us to do a smartWallet upgrade on every release until it's fixed.

Copy link
Member Author

Choose a reason for hiding this comment

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

Will add this back. I'm about to force push to a previous state prior to e75914c and resolve conflicts.

Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like you're right. I don't see tests for ZCF, or PriceAdminRegistry.

yarn ava initial.test.js

# test more, in ways that change system state
yarn ava ./*.test.js
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't believe so. I'd also prefer switching to a wildcard invocation.

@mujahidkay mujahidkay force-pushed the mk/revise-a3p-post-u18 branch from 3e1615b to 1a188be Compare January 27, 2025 19:51
@mujahidkay mujahidkay force-pushed the mk/revise-a3p-post-u18 branch from 1a188be to 69dc2a7 Compare January 27, 2025 20:01
Copy link
Member

Choose a reason for hiding this comment

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

We probably need to adapt this file to the expected vat upgrades of u19

Copy link
Member Author

@mujahidkay mujahidkay Jan 28, 2025

Choose a reason for hiding this comment

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

I worked on this today. And this only seems valid if the upgrades are triggered via core proposals, right? The current state of this PR keeps the vat upgrades as core evals, apart from a couple, all others have corresponding tests that verify incarnation number after core eval is applied.

P.S. vat names I used (locally. apart from psmVats which didn't match for some reason) picked from here

const vats = {
    walletFactory: { incarnation: 6 },
    'zcf-b1-92c07-reserve': { incarnation: 1 },
    priceAuthority: { incarnation: 1 },
    agoricNames: { incarnation: 1 },
    '-provisionPool-governor': { incarnation: 1 },
    '-provisionPool': { incarnation: 1 },
    // ...psmVats,
    ...mintHolderVats,
};

BTW, I did uncomment the core proposals and got this test to pass with updated incarnation numbers but that resulted in failure of other tests (since I commented out evalBundles from tests).

We probably need to adapt this file to the expected vat upgrades of u19

I am not sure if this is required for this PR to merge, or should this be done in #10901. Please confirm @mhofman

Copy link
Member

Choose a reason for hiding this comment

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

this only seems valid if the upgrades are triggered via core proposals, right?

should this be done in #10901.

The content will change when upgrades are going through as core proposals but this PR should keep the file. If this PR doesn't run core proposals and postpones that to #10901, then yes that PR is in charge of updating the file with the new incarnation numbers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
force:integration Force integration tests to run on PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants