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

Generalize naming of new versioning "state version" -> "migrate version" #2164

Closed
webmaster128 opened this issue Jun 1, 2024 · 1 comment · Fixed by #2166
Closed

Generalize naming of new versioning "state version" -> "migrate version" #2164

webmaster128 opened this issue Jun 1, 2024 · 1 comment · Fixed by #2166
Milestone

Comments

@webmaster128
Copy link
Member

webmaster128 commented Jun 1, 2024

(Follow-up to #2116)

The new migrate versioning coming in 2.1 uses integers to go from old to new version in a way that allows convenetly supporting a variety of old versions. This way not all instances need to be on the latest version to be able tto upgrade. Migrate code then looks more or less like this:

#[entry_point]
#[state_version(6)]
pub fn migrate(deps: DepsMut, env: Env, msg: MigrateMsg) -> StdResult<Response> {

    // if statements mimic a C/C++/Java swich statement with fallthrough semantics

    if (old_version <= 3) {
        panic("Unsupported version, migrate to intermediate version first");
    }

    if (old_version <= 4) {
        // add a field to config and set a default value
    }

    if (old_version <= 5) {
        // copy some data from old format to new
    }

    if (old_version <= 6) {
        // Send funds to community pool
    }

    if (old_version > 6) {
        panic("Downgrades are not supported");
    }
}

and if old_version equals the #[state_version(6)], the migrate entry point is not called.

Now @AmitPr brought up is that in practice, not all actions in the migrate entry point are state layout changes. Sometimes you just send funds around. Maybe you could elaborate on non-state layout changing migrations?

But the point is: we can simply generalize the naming to e.g. "migrate version".

cc @kulikthebird

@webmaster128 webmaster128 added this to the 2.1.0 milestone Jun 1, 2024
@AmitPr
Copy link
Contributor

AmitPr commented Jun 1, 2024

Re:non-state changing migrations: For example, some of our contracts have had cases where rounding issues or other logic-related issues caused funds to sit in the contract when they should have been sent elsewhere.

To fix this, we would patch the logic in the contract, and create a migration to incorporate this change, and to also transfer any funds that were locked in the contract due to this type of bug. There were no state changes -- only WASM binary changes, but we still made use of the migrate function to clean up things like bank balances (or, in some cases, calling into other external contracts, etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants