fix: Prevent and clean up zero-valued entries in Alpha storage maps during hotkey and coldkey swaps

[bittoby]

Description

Prevent and clean up zero-valued entries in Alpha storage maps during hotkey and coldkey swaps.

Coldkey and hotkey swap logic was inserting zero-valued entries into Alpha, TotalHotkeyShares, TotalHotkeyAlphaLastEpoch, and AlphaDividendsPerSubnet without checking if the value was zero first. These entries persist indefinitely and bloat storage - a single coldkey swap could produce ~18k zero entries, and roughly 52% of Alpha entries on-chain are zero-valued.

This PR adds zero-guards to all insertion points in swap_coldkey.rs and swap_hotkey.rs, and includes a one-time migration to purge existing zero entries from the four affected storage maps.

Related Issue(s)

• Closes Alpha and hotkey storage maps accumulate persistent zero-valued entries #2398

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Breaking Change

No breaking changes.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Additional Notes

The migration collects the full Alpha map into memory before removing zero entries. This is intentional - mutating a Substrate storage map while iterating over it is unsafe. The other three maps are smaller and iterated directly. All four maps use HasMigrationRun to ensure idempotency.

[bittoby]

@open-junius Could you please review this PR? Welcome to any feedbacks.
thank you

[open-junius]

change the target branch as devnet-ready, not main.

[bittoby]

I changed target branch. Thanks! Ready to review

[open-junius]

please check https://github.com/opentensor/subtensor/pull/2509/changes, which also prevent some zero value insert. Could you include these storage into the PR.

[bittoby]

@open-junius Thanks for your feedback! I updated all following your feedback. Could you please review again?

[open-junius]

please merge the latest devnet-ready, will fix the e2e test.

[bittoby]

@open-junius I merged the latest devnet-ready. Could you take a look once more?
thank you

[evgeny-s]

@evgeny-s @open-junius did you check my description? Should I have to update my PR?

I would rather keep it with the migration. Please test it first on the mainnet clone, and use multi-block migration if needed. Let's see other opinions on this regard.
Also, it would be great to add several TS tests for this PR.

[bittoby]

@evgeny-s @open-junius did you check my description? Should I have to update my PR?

I would rather keep it with the migration. Please test it first on the mainnet clone, and use multi-block migration if needed. Let's see other opinions on this regard. Also, it would be great to add several TS tests for this PR.

I absolute agree with you. If possible, I want to keep migration in this PR, too. Now I am testing locally. After finishing, I will share result here. Thanks @evgeny-s

[bittoby]

@evgeny-s

Updated:

• Converted migration to multi-block on_idle approach - on_runtime_upgrade is O(1), cleanup runs one map per block across 4 phases
• Fixed claim_root.rs - added missing else { remove } branch for consistency
• Tested against Finney mainnet clone via build-patched-spec - node runs and produces blocks normally with the migration code
• Added TS e2e test for zero-alpha prevention
• Reverted unrelated check-node-compat.yml change

[bittoby]

@open-junius Thanks for your feedback. I removed e2e test. Please review again.

[bittoby]

@open-junius Could you tell me why assert-clean-merges testing failed?

[open-junius]

@open-junius Could you tell me why assert-clean-merges testing failed?

You can ignore it. we need merge the main back to devnet-ready sometimes if there is any hotfix in main branch.

[open-junius]

These testing failure doesn't seem to relate to my change. Please check the log. @open-junius
I see, it is common issue in devnet-ready branch. I noticed you split the data cleanup into phases.
Could you follow the method recommended by @evgeny-s to get the amount and time needed to run migration?

[bittoby]

I have updated the migration script more correctly:
It now uses remaining_weight to dynamically limit how many entries are processed per block instead of a fixed batch size. This helps prevent block timeouts on large maps.

[bittoby]

Tested on Finney mainnet clone via build-patched-spec:

• Alpha zero entries: ~580,000
• Time: ~14 min (70 blocks) to remove 99% of them

No OOM or block timeout issues.

[bittoby]

@open-junius @evgeny-s I'd like you review once more ^^. It works well for me

[open-junius]

I have updated the migration script more correctly: It now uses remaining_weight to dynamically limit how many entries are processed per block instead of a fixed batch size. This helps prevent block timeouts on large maps.

It is great, let me review it again.

[open-junius]

Tested on Finney mainnet clone via build-patched-spec:

• Alpha zero entries: ~580,000
• Time: ~14 min (70 blocks) to remove 99% of them

No OOM or block timeout issues.

Thanks for collect the data, it is vaulable.

[bittoby]

@sam0x17 @open-junius Could you re-run CI testing?

[bittoby]

Additionally, I added AlphaV2 and TotalHotkeySharesV2 to migration cleanup and revert out-of-scope LastRateLimitedBlock change.

Ready for review now. @open-junius @evgeny-s @sam0x17