-
Notifications
You must be signed in to change notification settings - Fork 215
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): extend governance test coverage for acceptance proposal #10555
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
7532428
to
3de052b
Compare
3de052b
to
1dd4589
Compare
20f9781
to
89e4be7
Compare
649cde3
to
72cbbc6
Compare
… contract upgrade (#10638) closes: #10562 ## Description This PR introduces changes to the provisionPool contract to allow the overriding of the PerAccountInitialAmount parameter, governed by the Economic Committee, during a contract upgrade. To achieve the above functionality, this PR introduces the following changes: - The PerAccountInitialAmount can now be injected into the contract through privateArgs by defining governedParamOverrides. - The handleParamGovernance method from the governance package was updated to include an aditional optional argument called `overrides` so it can be passed to the makeParamManagerFromTerms to manage the governed parameter during contract upgrades. The core-eval proposal used to upgrade provisionPool was also updated to fetch the current value of PerAccountInitialAmount set on Vstorage and include it on the new privateArgs. If the governedParamOverrides is not provided to the privateArgs during the contract upgrade, the value of PerAccountInitialAmount will reset to the default one set on the contract terms. ### Security Considerations ### Scaling Considerations ### Documentation Considerations ### Testing Considerations The existing unit tests for the inter-protocol and vats packages, as well as the a3p-integration tests, have been verified to continue passing with these changes. Additionally, these changes were tested against the governance acceptance tests in the a3p-integration which ensures that governed parameter values remain intact after a contract upgrade, as well as testing that, if not included in the governedParamOverrides on the core-eval proposal, the value of PerAccountInitialAmount will reset to the default one set on the contract terms. To maintain the scope of this PR, that test is not included here, however, it will be introduced in PR #10555, which is planned to be opened once this is merged. ### Upgrade Considerations
1b456eb
to
77f5205
Compare
d6e4578
to
842fa8a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice cleanup/enhancement of the governance driver.
*/ | ||
const getIncarnationFromDetails = async vatName => { | ||
const matchingVats = await getDetailsMatchingVats(vatName); | ||
const expectedVat = matchingVats.find(vat => vat.vatName === vatName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this fail if the name doesn't uniquely match a single vat? It seems like that could lead to surprising errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for bringing this to my attention.
An assert call was included to verify that expectedVat
is not undefined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That checks the difference between 0 and at least 1. I was asking whether we need to worry about the difference between 1 and more than 1. find
will return the first instance. Do we need to worry about getIncarnationFromDetails
returning a different vat than was intended because the vatName
would have matched more than one vat?
There was a problem hiding this 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 that should be a concern.
Assuming that getDetailsMatchingVats will return all vats that can be related with the provided vat name, and that vat names are unique, we can be confident that the strict equality operator will will one be true for the single instance that we intend to get.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add @file comments here and in ./upgrade-vaults.js
with mutual cross-references, and say that this one is intended to be generic and reusable, while the other does several things that are specific to upgrade-18.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change request addressed
/** @file copied from packages/agoric-cli */ | ||
// TODO DRY in https://github.com/Agoric/agoric-sdk/issues/9109 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand why we have to duplicate stuff from synthetic-chain
. If we can import from @agoric/internal
, why do we need to repeat code that's in agoric-cli
?
I looked around and didn't find where these functions were copied from. Are they in agoric-sdk?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That comment was kept from the original rpc.js file, which end up being deleted in a previous PR and reintroduced on this one.
I updated the description to reflect the current implementation of rpc.js.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One remaining substantive question
*/ | ||
const getIncarnationFromDetails = async vatName => { | ||
const matchingVats = await getDetailsMatchingVats(vatName); | ||
const expectedVat = matchingVats.find(vat => vat.vatName === vatName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That checks the difference between 0 and at least 1. I was asking whether we need to worry about the difference between 1 and more than 1. find
will return the first instance. Do we need to worry about getIncarnationFromDetails
returning a different vat than was intended because the vatName
would have matched more than one vat?
Co-authored-by: Chris Hibbert <[email protected]>
02c201f
to
bc1f87a
Compare
This pull request has been removed from the queue for the following reason: Pull request #10555 has been dequeued. The pull request has been synchronized by a user. You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it. If you want to requeue this pull request, you need to post a comment with the text: |
@Mergifyio requeue |
❌ This pull request head commit has not been previously disembarked from queue. |
closes: https://github.com/Agoric/BytePitchPartnerEng/issues/24
closes: #10708
Description
This PR has the objective of extending the a3p-integration acceptance proposal test coverage. More specifically, it intend to test that:
The test plan to verify that the parameters governed by the economicCommittee are intact when the contract is upgraded is:
Although more contracts are governed by economicCommittee, the ones selected to be included in this test case were
vaultFactory
andprovisionPool
. A detailed discussion on the rationale behind this decision can be found at https://github.com/Agoric/BytePitchPartnerEng/issues/24Note: The existing governance test and helper functions were refactored to allow the
makeGovernanceDriver
function to be contract agnostic, in order to be reused by vaultFactory, provisionPool and any other contract that is intend to be tested in the future.The test plan is to verify that the vstorage node published.committees.Economic_Committee.latestQuestion displays the history of proposed Economic Committee parameter changes is:
Security Considerations
No security considerations.
Scaling Considerations
The "Governance proposals history" test compares vstorage values against a hardcoded list, requiring manual updates to expectedParametersChanges for new proposals or tests that executes a EC governed param changes made prior to this test.
To prevent the halting the test when the developer does not update the hardcoded list, this test is only asserting that the value returned from the published.committees.Economic_Committee.latestQuestion vstorage node is not empty.
Then it will compare both lists and if any mismatches is found, it will:
Note that this solution may risks oversight and could lead to latent issues, so I am open a implement a new design if desired.
Documentation Considerations
We propose adding a table to the z:acceptance README file. This table will:
An issue was created to address this task.
Testing Considerations
The methods exported by
makeVstorageKit
at the@agoric/client-utils
package, seems to display an unexpected behaviour, more specifically, when using thereadFully
method to query Vstorage node full history.As a workaround, I updated the
makeVStorage
function atz:acceptance/test-lib/rpc.js
to follow the same implementation as themultichain-testing/tools/batchQuery.js.
The rational behind this decision is explained in detail on the issue #10574
If desired, I can add these changes to
@client-utils/src/vstorage.js
in a future PR, contribute to the ongoing effort of reducing the dependency of the acceptance test-lib.The order of execution of the acceptance tests had to be updated to make sure that the
governance.test.js
would run after the state-sync acceptance tests to prevent the behavior described here #10574Upgrade Considerations
No upgrade considerations.