Hi @ShooterIT, looks like the test produce some false positives. Looking at the test code it seems very timing dependent. Would you consider changing the simple delays with a more accurate check that probes the server state instead?

for the record, failed on CI for MacOS:

*** [err]: Kill rdb child process if its dumping RDB is not useful in tests/integration/replication.tcl
Expected [s 0 rdb_bgsave_in_progress] == 1 (context: type eval line 27 cmd {assert {[s 0 rdb_bgsave_in_progress] == 1}} proc ::start_server)

it looks like the one that fails is this one:

                # Slave1 disconnect with master
                $slave1 slaveof no one
                # Shouldn't kill child since another slave wait for rdb
                after 100
                assert {[s 0 rdb_bgsave_in_progress] == 1}

which is odd considering we already know the it's in progress by the previous wait_for_condition. maybe there was a race, and only one slave connected?
maybe increasing repl-diskless-sync-delay to more than 5 seconds is needed?

meanwhile, just to be on the safe side, i'm taking this commit out of 6.0.9

Copy that @oranagra @yossigo
My bad, i found. It fails when only one slave connected with master and another slave is slow to connect with master. I will make a PR asap.

I could reproduce it on oranagra:6.0.9 branch but i didn't reproduce on unstable(i also don't find failed daily action in this test last month ), do we improve sync implementation in next commits?

ohh, now it all makes sense.
6.0 doesn't have #6271