-
Notifications
You must be signed in to change notification settings - Fork 18
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: integrations for updating the contract code and config #807
Conversation
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 test
|
||
// Perform update to the contract and see that the nodes are still properly running and picking | ||
// up the new contract by first upgrading the contract, then trying to generate a new signature. | ||
let id = ctx.propose_update_contract_default().await; |
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.
Ideally, we should check for contract hash and ensure it changed to the one we were proposing. Signature production can work with the old one.
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.
Checking whether or not these values have been changed should just be reserved for the unit tests which we test against already. Integration tests are more about if the change makes it so that the nodes aren't running anymore. That being said, this test doesn't really do that quite yet. We should eventually add something like an invalid contract upgrade and see whether or not the nodes behave as expected
actions::single_payload_signature_production(&ctx, &state).await?; | ||
|
||
// Now do a config update and see if that also updates the same: | ||
let id = ctx.propose_update(ProposeUpdateArgs { |
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.
Same with config. We should propose something new, then fetch the config and compere it to what we proposed.
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.
Same thing I said in the previous comment, but we should see if introducing interesting configs would mess up the nodes or not like high concurrent introduction and concurrent generation
No description provided.