slipenkomk/valkey
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix flakiness of cluster-multiple-meets and cluster-reliable-meet (#728)

Browse Source 
Tests in cluster-multiple-meets were flaky as reported by @madolson 

*
https://github.com/valkey-io/valkey/actions/runs/9688455588/job/26776953320
*
https://github.com/valkey-io/valkey/actions/runs/9688455588/job/26776953585

I wasn't able to reproduce this locally, but I suspect that the
flakiness is coming from the fact that nodes are reported as "connected"
as long as there is an outgoing link. An outgoing link is created before
MEET is sent out.

Signed-off-by: Sankar <1890648+srgsanky@users.noreply.github.com>
This commit is contained in:
Sankar 2024-07-01 22:27:38 -07:00 committed by GitHub
parent 3323e422ad
commit eff45f5467
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 14 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
tests/unit/cluster/cluster-multiple-meets.tcl
View File

@ -51,7 +51,13 @@ tags {tls:skip external:skip cluster} {
} }
# 0 will be connected to 1, but 1 won't see that 0 is connected # 0 will be connected to 1, but 1 won't see that 0 is connected
assert {[llength [get_cluster_nodes 1 connected]] == 1} # Using a wait condition here as an assert can be flaky - especially
# when cluster nodes is processed when the link is established to send MEET.
wait_for_condition 1000 50 {
[llength [get_cluster_nodes 1 connected]] == 1
} else {
fail "Node 1 recognizes node 0 even though it drops PONGs from node 0"
}
assert {[llength [get_cluster_nodes 0 connected]] == 2} assert {[llength [get_cluster_nodes 0 connected]] == 2}
# Drop incoming and outgoing links from/to 1 # Drop incoming and outgoing links from/to 1

8
tests/unit/cluster/cluster-reliable-meet.tcl
View File

@ -50,7 +50,13 @@ tags {tls:skip external:skip cluster} {
} }
# Make sure the nodes still don't know about each other # Make sure the nodes still don't know about each other
assert {[llength [get_cluster_nodes 1 connected]] == 1} # Using a wait condition here as an assert can be flaky - especially
# when cluster nodes is processed when the link is established to send MEET.
wait_for_condition 1000 50 {
[llength [get_cluster_nodes 1 connected]] == 1
} else {
fail "Node 1 recognizes node 0 even though node 0 drops MEETs from node 1"
}
assert {[llength [get_cluster_nodes 0 connected]] == 1} assert {[llength [get_cluster_nodes 0 connected]] == 1}
R 0 DEBUG DROP-CLUSTER-PACKET-FILTER $CLUSTER_PACKET_TYPE_NONE R 0 DEBUG DROP-CLUSTER-PACKET-FILTER $CLUSTER_PACKET_TYPE_NONE