Test Plan: v23-feeDistributor upgrade

[anilhelvaci]

What is the Problem Being Solved?

We need to test feeDistributor keeps working after an upgrade in Emerynet and any other test networks that are required.

Description of the Design

Features to test	a3p local net	Test Net (Emerynet, XNet..)	Form	Verify
Fees sent to reserve	yes	yes	agd	* published.reserve.metrics updated with;    - correct amount    - correct interval
Disable old one	yes	yes	core eval	observe from the logs: agoric-sdk/packages/inter-protocol/src/proposals/replace-fee-distributor.js Line 127 in 3b478fb trace('Old collectors cleared. Start creating and setting new ones.');
Shorter collectionInterval	yes	yes?	core eval	check published.reserve.metrics

Security Considerations

Not expecting any security complications. Worst thing that I can think of about these tests failing to catch a bug is that the fees accrued stay in vaultFactory and not get transferred to reserve. Would appreciate to be reminded of any possible complications I might have been missed.

Scaling Considerations

Not a major issue.

Test Plan

flowchart LR
    A@{ shape: circle, label: "Upgrade 19 CoreEvals finish" } --> B(observe in the logs)
    B --> C(collectionInterval is correct in feeDistributor terms) --> I
    B --> D(peridodicCollectors don't throw after stop is called) --> I
    B --> E(feeDistributorKit, feeDistributor and periodicFeeCollectors resetted) --> I
    A --> F(Open a vault)
    subgraph Repeat-3-times
    F -- timeout after collectionInterval --> G(wait until reserve receives fee)
    G --> H@{ shape: framed-circle, label: "Stop" } --> F
    end
    Repeat-3-times --> I@{ shape: framed-circle, label: "Stop" }

Loading

Thinking about preparing a script that executes above logic using agoric-cli and @agoric/client-utils.

Upgrade Considerations

This is intended to be a workspace for laying out the plan for testing feeDistributor replacement on the test networks such as Emerynet, Xnet Devnet.

[anilhelvaci]

assigned you for review @Chris-Hibbert

[Chris-Hibbert]

I like this format, with the verify column, and an indication of what log message to look for.

We'd also like to see an indication of what to look for on MainNet. Since we'll have passed multiple tests in a3p and on various testNets, this should mostly be indications that the upgrade took place, and checks of any new functionality that may have been introduced. When an upgrade doesn't succeed, the previous incarnation will still be present, so the fact that you can interact with it doesn't provide evidence that the upgrade happened.

For most contracts, the upgrade line vat v9 upgraded from incarnation 2 to 3 with source b1-0239dcade2176116 will be sufficient. With so many contracts upgrading, I think we should make a list of upgrades to check for.

[anilhelvaci]

Since we'll have passed multiple tests in a3p and on various testNets

So I'm struggling to picture what those "...passed multiple tests" could be on testNets. What I understand is;

• If there is a behavioral change for a certain vat, test it
• If not, only thing we can do is to observe upgrade message from the logs
  • this is because, if there's no behavioral change the old vat will keep up the old behavior there will be no way to tell other than the incarnation message printed to the logs

Could you confirm?

[Chris-Hibbert]

if there's no behavioral change the old vat will keep up the old behavior there will be no way to tell other than the incarnation message printed to the logs

That's mostly right. I neglected to mention that we can also look up the incarnation number. In A3P, we have tools that access the DB. We could add a step after softwareUpgrades that upgrade more than a few vats to print a list of all the incarnation numbers and cross-check them. For U19, this would be useful.