Flaky test: `basic_migration_with_native_tokens` fails non-deterministically due to HashMap iteration order

[Thoralf-M]

Summary

The test iota_genesis_builder::stardust::migration::tests::basic::basic_migration_with_native_tokens failed intermittently in CI on PR #11697 (attempt 1 of the "Run rust tests" job, job ID 80802386929). The run was rerun and passed on attempt 2. The failure was a Rust unwrap() panic at crates/iota-genesis-builder/src/stardust/migration/tests/basic.rs:352.

Failure evidence

• PR: feat(iota-core): backfill epochs_v2 and seed it on snapshot restore #11697 (merged)
• Workflow run: https://github.com/iotaledger/iota/actions/runs/27347670975
• Failed job (attempt 1): https://github.com/iotaledger/iota/actions/runs/27347670975/job/80802386929
• Backtrace:

  4: iota_genesis_builder::stardust::migration::tests::basic::basic_migration_with_native_tokens
             at ./src/stardust/migration/tests/basic.rs:352:6
  5: iota_genesis_builder::stardust::migration::tests::basic::basic_migration_with_native_tokens::{{closure}}
             at ./src/stardust/migration/tests/basic.rs:308:40
  

Root cause analysis

Two sources of non-determinism interact in this test:

1. random_output_header() is called for each of the 10 foundry outputs created in the test loop (lines 320–337). This gives each native token a random Object ID, making the order of objects in the execution result's written map unpredictable across runs.

2. written.values().find(...) inside extract_native_tokens_from_bag() (in tests/mod.rs) iterates over a HashMap's values in an arbitrary order to locate the expected coin object. When combined with the randomised Object IDs above, the lookup can fail to match the correct coin object and returns Err("missing coin object") — which then propagates to the .unwrap() at basic.rs:352.

Expected behaviour

The test should pass deterministically regardless of Object ID assignment or HashMap iteration order. The lookup logic should not rely on HashMap iteration order to correlate native-token coins with their expected types.

Suggested fix

Replace the HashMap::values().find(...) approach with a lookup keyed on a stable identifier (e.g. the struct tag or token ID) so that the result does not depend on iteration order. Alternatively, use a deterministic data structure (BTreeMap) for the written map if iteration order matters to the test assertions.

[minato32]

@Thoralf-M I'd like to work on this. Could a maintainer assign the issue to me so the linked-issue check passes when I open the PR? Plan: switch the written lookup in extract_native_tokens_from_bag (crates/iota-genesis-builder/src/stardust/migration/tests/mod.rs) to a stable-key lookup keyed by the coin's StructTag instead of HashMap::values().find(...), so the result no longer depends on iteration order.

[Thoralf-M]

Hi @minato32 assigned you, let me know if you have any questions

[Thoralf-M]

Closing as transient, not a code bug.

Re-reading the backtrace, the panic propagates from run_migration (tests/mod.rs:253), not the coin lookup: the Move build of a generated foundry package failed while updating its Iota git dependency (git reset --hard origin/framework/genesis/mainnet, exit 128) during migrate_foundries — a network / git-dependency hiccup, not HashMap iteration order. It hasn't recurred since, so it's not worth a code change right now.

If it does resurface: the fragility is the live fetch + reset against a moving branch on every package build (skip_fetch_latest_git_deps: false in package_builder.rs), which also swallows the underlying git error — so the real reason won't show in the log. That's where a fix would go, not in the test's coin lookup.

Thanks @minato32 for investigating. Closing as not planned.

---

Generated by Claude Code