You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the last commit broke our assumption that a randomly ordered slice of nodes will consistently return the same node for the same hash. The following test code fails on the current HEAD of master and works fine with the previous commit:
func TestStableHashring(t *testing.T) {
nodes := []string{"NODE_1", "NODE_2", "NODE_3", "NODE_4", "NODE_5"}
hash := "HASH"
var constantNode string
for i := 0; i < 100; i++ {
rand.Shuffle(len(nodes), func(i, j int) { nodes[i], nodes[j] = nodes[j], nodes[i] })
hr := New(nodes)
n, ok := hr.GetNode(hash)
if !ok {
t.Error("error getting node")
}
if constantNode == "" {
constantNode = n
}
if n != constantNode {
t.Errorf("nodes are not equalt %s != %s", n, constantNode)
}
}
}
Is this a falsey assumption or did the latest changes introduce an unintended behaviour?
Cheers,
Dennis
The text was updated successfully, but these errors were encountered:
I'm curious of the intention here too; I had to fork with a revert commit, as this broke a desired behavior; I was using this for consensus among multiple servers, but that doesn't work well if they don't agree on anything.
Hi everyone,
the last commit broke our assumption that a randomly ordered slice of nodes will consistently return the same node for the same hash. The following test code fails on the current HEAD of master and works fine with the previous commit:
Is this a falsey assumption or did the latest changes introduce an unintended behaviour?
Cheers,
Dennis
The text was updated successfully, but these errors were encountered: