v0.50 in-place upgrade for live mantle-1 is unrehearsed (fresh-genesis sim gates prove nothing about migration)

Open
#110 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
go
Domain
distributed-systems, release

Research direction

Start with the upgrade handler's RunMigrations path and the StoreUpgrades.Added configuration on the rwa/phase2-sdk-upgrade branch, then compare them with an actual mantle-1 state export. Rehearse the upgrade by halting at the upgrade height, swapping the binary, and resuming; done means real state migrates cleanly and the rehearsal is a release gate.

Written by the indexing model from the issue text.

Description

The rwa/phase2-sdk-upgrade branch now boots and the four sim gates pass, but every gate starts from fresh genesis and validates zero migration behavior. The live mantle-1 chain (running the deployed v1.x binary, SDK v0.47-era) must upgrade in place, and that path has never been exercised.

What is unverified (grounded)

  • The upgrade handler runs RunMigrations for the v0.4x -> v0.50 module migrations; none of these run in the sim (fresh genesis skips migration). The legacy x/params key tables were registered so migrations do not panic on a missing table, but whether each module's actual stored params migrate cleanly from mainnet bytes is untested.
  • StoreUpgrades.Added was corrected to {crisis, consensus} by comparing against the deployed binary's store list from memory; this must be re-derived against an actual mainnet store export, not assumed.
  • Applied-plan name v2.0.0 replaces the burnt v1-Yellow Spaceship (verified applied at height 7,135,001 via rest.assetmantle.one). Correct, but the height/skip wiring is only meaningful once tested against real state.

Proposed fix (no code decision needed to start)

Export current mantle-1 state, run an in-place-testnet upgrade rehearsal (halt at the upgrade height, swap binary, resume), and make that rehearsal a release gate. Derive StoreUpgrades.Added and any param migration from the rehearsal, not from inspection.

Fix-priority scorecard

SEC UX AUTO YAGNI DELTA FIN
75 30 25 60 20 43

SEC high (a botched live upgrade halts/corrupts a chain holding real value); AUTO low (needs mainnet export + human-judged rehearsal), so this is a human-decision item, not autonomous-fix.

Dominant language
Go
Stars
42
Forks
16
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AssetMantle/node

All issues in AssetMantle/node

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.