Skip to content

Conversation

timvisee
Copy link
Member

Fix similar to #5838, but for shard key mappings in the consensus snapshot.

Our consensus snapshot also serializes shard key mappings in an unstable way. It may cause the data to be parsed differently during deserialization.

This PR fixes the problem with a wrapper type. It is used as compatibility layer because we still need to support older versions as well. Eventually we'll fully move to the new type to totally eliminate this problem.

Please see #5838 for more details.

All Submissions:

  • Contributions should target the dev branch. Did you create your branch from dev?
  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

  1. Does your submission pass tests?
  2. Have you formatted your code locally using cargo +nightly fmt --all command prior to submission?
  3. Have you checked your code using cargo clippy --all --all-features command?

@timvisee timvisee requested review from generall and ffuugoo March 20, 2025 13:12

This comment was marked as resolved.

coderabbitai[bot]

This comment was marked as resolved.

@timvisee timvisee merged commit c36cc07 into dev Mar 20, 2025
17 checks passed
@timvisee timvisee deleted the fix-shard-key-mapping-losing-number-consensus-snapshot branch March 20, 2025 14:12
timvisee added a commit that referenced this pull request Mar 21, 2025
* Use safe shard key wrapper type in consensus snapshot state

* Add shard ID iterator

* Produce net wrapped shard key mapping type directly

* Add useful comments

* Fix typo
@timvisee timvisee mentioned this pull request Mar 21, 2025
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 this pull request may close these issues.

2 participants