Fix CLUSTERSCAN fingerprint to use configurable_hash_seed#3679
Merged
Conversation
This bug was introduced in valkey-io#3366. Before PR valkey-io#3366, hash-seed config was applied directly via hashtableSetHashFunctionSeed(), so clusterscanFingerprint() correctly used hash_function_seed to derive the fingerprint. PR valkey-io#3366 introduced a separate configurable_hash_seed for data hashtables and kept hash_function_seed as a random per-process value. However, clusterscanFingerprint() was not updated accordingly — it still reads hash_function_seed, which is now random on every node. This makes fingerprints differ across nodes even when they share the same hash-seed config, causing cursors to restart on failover. Signed-off-by: Binbin <binloveplay1314@qq.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## unstable #3679 +/- ##
============================================
+ Coverage 76.71% 76.73% +0.02%
============================================
Files 162 162
Lines 80656 80656
============================================
+ Hits 61872 61892 +20
+ Misses 18784 18764 -20
🚀 New features to boost your workflow:
|
zuiderkwast
approved these changes
May 12, 2026
zuiderkwast
left a comment
Contributor
There was a problem hiding this comment.
Good catch!
We should have had this test case from before. It would have caught the bug.
sarthakaggarwal97
approved these changes
May 12, 2026
sarthakaggarwal97
left a comment
Contributor
There was a problem hiding this comment.
Nice find! Looks good to me! Thank you!
Contributor
|
#3366 is not included in 9.1, so also this PR should not be included in 9.1. I changed it to 10.0. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This bug was introduced in #3366.
Before PR #3366, hash-seed config was applied directly via
hashtableSetHashFunctionSeed(), so clusterscanFingerprint() correctly
used hash_function_seed to derive the fingerprint.
PR #3366 introduced a separate configurable_hash_seed for data
hashtables and kept hash_function_seed as a random per-process value.
However, clusterscanFingerprint() was not updated accordingly — it
still reads hash_function_seed, which is now random on every node.
This makes fingerprints differ across nodes even when they share the
same hash-seed config, causing cursors to restart on failover.
CLUSTERSCAN was introduced in #2934.