-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
[cli] Implement upgrade compatibility checks client side #19562
base: main
Are you sure you want to change the base?
[cli] Implement upgrade compatibility checks client side #19562
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
TestsStill thinking about test strategy however I have run through most tests manually. UpgradeErrorsV1.move
Upgrade to -> UpgradeErrorsV2.move
Output
|
029cb66
to
3785e49
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.
The core of this change looks great -- one thing to note is that we do still need to pay attention to which checks are enabled in the Compatibility
struct when we finish
, but otherwise this logic looks good.
Main thing to work on before landing is to polish the content of error messages (and figure out the testing strategy).
15c6b91
to
0c1fd4e
Compare
ac4a8c3
to
594c093
Compare
594c093
to
596617d
Compare
Compatibility::upgrade_check().check_with_mode::<CliCompatibilityMode>( | ||
&Module::new(&existing_module), | ||
&Module::new(new_module), | ||
)?; |
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.
pass in OLD then NEW. fixes the issue we saw last week, falls under the tests.
b4297e1
to
30d0043
Compare
3b3fcf9
to
380d989
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.
Thanks @jordanjennings-mysten -- comments are mostly clean-ups, but the most important one to address is the one about dependencies to Sui
in test packages -- we should use a "local" dep for that, rather than a "git" dep to avoid making CI times longer.
Otherwise this is good to go, accepting to unblock!
# TODO remove once compatibility check is fully finished | ||
# not meant for long term use | ||
compatibility-check-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.
To be honest, I would just pull the relevant changes out into their own commit so I could keep working on them locally, but land the rest of the stuff. Working on the formatting so we can enable this feature is going to be our immediate next step, so I wouldn't worry about checking in what you've already got (integration-wise) gated behind a feature.
edition = "2024.beta" # edition = "legacy" to use legacy (pre-2024) Move | ||
|
||
[dependencies] | ||
Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework/packages/sui-framework", rev = "framework/testnet" } |
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.
Better to use a "local" dep for Sui
in tests -- otherwise these tests will be slower and more flaky because they involve a network call out to fetch the git repo.
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.
(ditto for all the other manifests)
assert!(result.is_err()); | ||
let err = result.unwrap_err(); | ||
|
||
assert_debug_snapshot!(err); |
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 the debug snapshot has quite worked here -- it's still converting to a string, and then it's showing the debug of that, which is not what we want. If we want Debug
to work, I think you need to drop the Error
impl for the error type and all the associated #[error(...)]
annotations, (I think that's fine to do, because your proposed error format is not likely to re-use that) or alternatively, switch to a regular assert_snapshot!
and use the current string format.
Description
Introduce client side upgrade compatibility checking, allowing users to check before TX submission if an upgrade will be successful. Improves the output of errors by relying on the move-binary-format crates checks to list the issues with the error to the user that are found.
Test plan
manually tested see comment below
Release notes
User will see a different error when an upgrade error is thrown which includes the details of each error.