`migrate` has only ever been exercised for a single version transition

[Ejirowebfi]

🔴 Critical · contracts/token-factory/src/lib.rs:831-849

Description

CURRENT_SCHEMA_VERSION is 1, and migrate's only branch is if on_chain_version < CURRENT_SCHEMA_VERSION stamping the version onto pre-versioned state. The README's own "Adding a new migration" section documents the intended pattern for a future N → N+1 step, but that pattern has never actually been exercised in this codebase because there has only ever been one version. The very first real schema change will be the first time this migration framework is tested against anything beyond the trivial 0→1 bootstrap case, which is exactly the wrong time to discover the pattern doesn't compose (e.g., does calling migrate on a contract that's 2 versions behind correctly apply both incremental steps, or does the if on_chain_version < CURRENT_SCHEMA_VERSION structure as documented actually only support a single flat jump, silently skipping intermediate per-version logic if future contributors follow the README's if on_chain_version < N+1 { ... } pattern literally and stack multiple such blocks without chaining on_chain_version reads correctly between them)?

Tasks

• Add a synthetic #[cfg(test)]-only "version 2" migration step to test.rs (not shipped in production lib.rs) that adds a hypothetical new field, to prove out the multi-step migration pattern end-to-end without committing to a real schema change prematurely.
• Write a test that seeds on-chain state at version 0 (pre-versioning) and asserts migrate correctly walks through both the 0→1 and the synthetic 1→2 steps in one call, ending at the synthetic version 2 with all fields correctly defaulted.
• Write a test that seeds state at version 1 and confirms migrate applies only the remaining 1→2 step, not re-running 0→1 logic.
• Once validated, update the README's migration-authoring instructions if the synthetic test reveals the documented pattern needs adjustment (e.g., clarifying that each version's if block must read and compare against the current on_chain_version at the time it runs, not a value captured before any migration step executed).

Acceptance Criteria

• A synthetic multi-step migration test exists, passes, and is clearly marked as test-only scaffolding (not a real schema version).
• The README's migration instructions are verified accurate against this test, with any discovered gaps corrected.

[paud1615-tech]

Hello maintainer I who like to work on these issues can u assign it to me pls

[olaayoade91-byte]

Hello @maintainer, I understand the expected outcome and would love to work on this. I'll provide a solution that satisfies the acceptance criteria.

[grantfox-oss]

🦊 GrantFox — @olaayoade91-byte has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #919)
2. Your PR will be reviewed by the Favourorg maintainers

Good luck! Track your progress on GrantFox.