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

Repair u19 tests in a3p-integration #10947

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

Conversation

Chris-Hibbert
Copy link
Contributor

closes: #10901

Description

In clean-up after upgrade-18, the upgrade 19 tests were left in an incomplete state. This ensures they are running again.

Security Considerations

Not a security issue.

Scaling Considerations

No implications.

Documentation Considerations

N/A

Testing and Upgrade Considerations

Our practice is to have a3p-integration represent upcoming upgrades to test them in the context of previous upgrades on chain. There were issues getting the U19 tests in proper condition before U18, and so revising them once U18 had been added to the chain was a little wonky. After this PR, The tests demonstrate that U19 will succeed, and the acceptance tests will verify the state of the chain after the upgrade.

@Chris-Hibbert Chris-Hibbert added deployment Chain deployment mechanism (e.g. testnet) test Testnet contract-upgrade labels Feb 5, 2025
@Chris-Hibbert Chris-Hibbert self-assigned this Feb 5, 2025
@Chris-Hibbert Chris-Hibbert requested a review from a team as a code owner February 5, 2025 17:31
@Chris-Hibbert Chris-Hibbert marked this pull request as draft February 5, 2025 17:31
Copy link

cloudflare-workers-and-pages bot commented Feb 5, 2025

Deploying agoric-sdk with  Cloudflare Pages  Cloudflare Pages

Latest commit: f351299
Status: ✅  Deploy successful!
Preview URL: https://ae42fcab.agoric-sdk.pages.dev
Branch Preview URL: https://10901-repair-u19.agoric-sdk.pages.dev

View logs

@Chris-Hibbert Chris-Hibbert added the force:integration Force integration tests to run on PR label Feb 5, 2025
@Chris-Hibbert Chris-Hibbert marked this pull request as ready for review February 5, 2025 21:01
@Chris-Hibbert Chris-Hibbert requested review from turadg and dckc February 5, 2025 23:16
@Chris-Hibbert
Copy link
Contributor Author

@turadg, j@dckc, I've added you both as reviewers but it should only take one of you. Do you want to decide which is more available?

@@ -10,7 +10,7 @@ const vats = {
orchestration: { incarnation: 1 },
transfer: { incarnation: 2 },
walletFactory: { incarnation: 6 },
zoe: { incarnation: 4 },
zoe: { incarnation: 3 },
Copy link
Member

Choose a reason for hiding this comment

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

how did this number go down?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't know for sure how the test passed with this number. My guess would be that the code last ran in an environment where a Zoe upgrade was included with U18 or the proto U19.

The lower number is correct following U18, and in a U19 that doesn't upgrade Zoe.

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 because upgrade.go somehow kept some u18 proposals around when it was rebased on top of u18.

@@ -24,8 +24,6 @@ const sendBankAsset = async powers => {
const valueStr = '{{VALUE}}';
const value = BigInt(valueStr)

console.log(`Start sendBankAsset for ${label}`);
Copy link
Member

Choose a reason for hiding this comment

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

seems useful but you'd know better since you've been debugging

} from './test-lib/mintHolder-helpers.js';
import { networkConfig } from './test-lib/index.js';

test('mintHolder contract is upgraded', async t => {
test('verify mintHolder contract upgrade', async t => {
Copy link
Member

Choose a reason for hiding this comment

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

nit: "test" is already a verb

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm. I read the string argument as the name of the test, rather than a noun phrase describing what is to be tested. In this case the test used to perform the upgrade (because the proposal was a coreEval), and now only verifies it (because it's now a software upgrade).

"testing/add-USD-OLIVES.js agoricNamesCoreEvals/addUsdOlives",
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo",
"vats/upgrade-mintHolder.js upgrade-mintHolder A3P_INTEGRATION"
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo"
Copy link
Member

Choose a reason for hiding this comment

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

all these proposals for testing should be under test/ so they don't invalidate the "use" image. see,

Making that change affects .gitignore and .tsconfig but if you put them under a path like test/submissions then you can use that pathname for those files and not have to manage a list of submissions.

We'll make this easier eventually,

Copy link
Member

Choose a reason for hiding this comment

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

Actually they should be in host, and their core eval output should be in test

Something like

Suggested change
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo"
"host/testing/publish-test-info.js test/agoricNamesCoreEvals/publishTestInfo"

Copy link
Member

Choose a reason for hiding this comment

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

FYI @Chris-Hibbert , the host thing hasn't landed in a3p. Up to you whether to wait for it to be merged and released to NPM so you can include that synthetic-chain lib version in this PR.

Copy link
Member

Choose a reason for hiding this comment

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

I like your test/generated approach. It still copies to the image unnecessarily, but it's only the test image so it doesn't invalid any extra. (If the proposal changes its build would anyway). I think it's better to keep test stuff together than to spread it into another path.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah you're right, a change in the proposal building would likely invalidate everything anyway, but collocating test files together is cleaner.

I got confused about the host stuff however, I forgot these first argument is relative to the SDK packages.

// if variant == "" {
// return nil, nil
// }
func restartFeeDistributorCoreProposal(targetUpgrade string) (vm.CoreProposalStep, error) {
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 not reviewing any of the Golang in this PR

});
};

const Usage = `agoric run replace-feedDistributor-combo.js ${[...knownVariants, '<json-config>'].join(' | ')}`;
Copy link
Member

Choose a reason for hiding this comment

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

surprising casing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it matches replace-feeDistributor.js.

I don't have an objection to this form. If you want something different, please say what would be better.

Copy link
Member

@turadg turadg Feb 10, 2025

Choose a reason for hiding this comment

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

Oh I meant on Usage. I've mostly seen USAGE. But searching the codebase I see we have a number of each of these:

  • const USAGE =
  • const Usage =
  • const usage =

nvm

/** @type {import('@agoric/deploy-script-support/src/externalTypes.js').DeployScriptFunction} */
export default async (homeP, endowments) => {
const { scriptArgs } = endowments;
const variantOrConfig = scriptArgs?.[0];
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 not familiar with this convention. Please factor it out into a reusable function with documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

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.

It's a little unfortunate we have more need for variants. But since that's already the case for the mintHolder I won't block on that.

"testing/add-USD-OLIVES.js agoricNamesCoreEvals/addUsdOlives",
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo",
"vats/upgrade-mintHolder.js upgrade-mintHolder A3P_INTEGRATION"
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo"
Copy link
Member

Choose a reason for hiding this comment

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

Actually they should be in host, and their core eval output should be in test

Something like

Suggested change
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo"
"host/testing/publish-test-info.js test/agoricNamesCoreEvals/publishTestInfo"

@@ -29,38 +27,19 @@ test.before(async t => {
};
});

test.serial('simulate trade of IST and USDC', async t => {
test.serial('check stats pre-swap', async t => {
Copy link
Member

Choose a reason for hiding this comment

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

I won't block on this, but we've been abusing test.serial. Its only guarantee is "not serial" and we've been relying on it being sequential.

You mean "not concurrent". I honestly didn't realize it didn't guarantee sequential.

builderScript,
"defaultProposalBuilder",
map[string]any{
"variant": variant,
Copy link
Member

@mhofman mhofman Feb 7, 2025

Choose a reason for hiding this comment

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

Really unfortunate we still have the need for variants in this upgrade. We need to find a way out of this pickle, but I'm not gonna try to figure out why this upgrade needs special casing per network now.

In the mean time, we can hopefully prioritize #10837

Edit: filed #10956

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've read #10837 and don't understand the path forward.

This distinction is because we want to be able to validate the feeDistributor, and waiting a full hour-long cycle for it seems infeasible. We have other timing-related variations for auctions. In order to get rid of variant configurations for test, we need another solution.

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 my core question was why these config have to be provided as core proposal argument, and cannot be stored in the config of the contract we're upgrading. That's what #10956 asks. We can punt on it for now.

Comment on lines 186 to 187
// because of #10794, we need to do at least a null upgrade of
// the walletFactory on every software upgrade
Copy link
Member

Choose a reason for hiding this comment

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

Looks like the comments needs formatting (weird indentation)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@@ -10,7 +10,7 @@ const vats = {
orchestration: { incarnation: 1 },
transfer: { incarnation: 2 },
walletFactory: { incarnation: 6 },
zoe: { incarnation: 4 },
zoe: { incarnation: 3 },
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 because upgrade.go somehow kept some u18 proposals around when it was rebased on top of u18.

import { getManifestForReplaceFeeDistributor } from '@agoric/inter-protocol/src/proposals/replace-fee-distributor.js';
import { SECONDS_PER_HOUR } from '@agoric/inter-protocol/src/proposals/econ-behaviors.js';

const configurations = {
Copy link
Member

Choose a reason for hiding this comment

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

So I'll bite. Why do these config need to be hard coded in the builder? Can't they be restored from whatever params are currently on the respective chain, removing the need for variants?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The feeDistributor in a3p-integration currently has the same parameter settings as on mainNet. We want to run tests that verify that fees are distributed. Without a change, the test would have to wait an hour. We make similar changes with changes to timing for tests for other vats, like auctions.

Copy link
Member

Choose a reason for hiding this comment

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

And we can't update these parameters outside of the core proposal, through a core eval or other governance vote, either before the upgrade, or after in the test?

@@ -62,6 +62,12 @@ export const mintPayment = async (t, address, assetList, value) => {

for (const asset of assetList) {
const { label, denom } = asset;

// XXX I don't know what asset shows up like this, but let's ignore it.
Copy link
Member

Choose a reason for hiding this comment

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

please indicate why it's okay to ignore

"testing/add-USD-OLIVES.js agoricNamesCoreEvals/addUsdOlives",
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo",
"vats/upgrade-mintHolder.js upgrade-mintHolder A3P_INTEGRATION"
"testing/publish-test-info.js agoricNamesCoreEvals/publishTestInfo"
Copy link
Member

Choose a reason for hiding this comment

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

I like your test/generated approach. It still copies to the image unnecessarily, but it's only the test image so it doesn't invalid any extra. (If the proposal changes its build would anyway). I think it's better to keep test stuff together than to spread it into another path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contract-upgrade deployment Chain deployment mechanism (e.g. testnet) force:integration Force integration tests to run on PR test Testnet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

u19 is not acceptance tested
4 participants