flake(tests): redis-tls decides on the replica link before it is up #4238

Describe the bug

redis-tls reads INFO replication from both Redis pods once and fails the test outright when a replica reports role:slave without master_link_status:up. A link that is still coming up is a normal transient, so the check decides on a state that has not settled yet.

hack/e2e-chainsaw/redis/chainsaw-test.yaml, in step verify-tenant-ca-projection:

*role:slave*)
  case "$info" in
    *master_link_status:up*) linked=$((linked + 1)) ;;
    *) echo "rfr-redis-secure-$i replicates with no link up" >&2; exit 1 ;;
  esac
  ;;

There is no retry, and that is deliberate. The step says so above it:

# Deterministic once the asserts above have passed, so no retry.

The run below is the counter-example. The block's own comment already doubts the premise, for a neighbouring reason:

# but the readiness script exits 0 for anything reporting
# role:master, so a link that breaks afterwards is invisible to it.

Readiness witnessing the bootstrap does not imply the replica link is up at the moment this script looks, which is what the failure shows.

Environment

• Cozystack: main
• In-tree e2e lane, container sandbox

To Reproduce

Run the e2e suite. It passes most of the time; the failure needs the check to land while the replica link is still establishing.

Expected behaviour

The step waits for the topology to converge, the way the rest of the suite waits for what it asserts, and fails only when it does not converge in time.

Actual behaviour

One sampling decides the test:

=== STDERR
rfr-redis-secure-1 replicates with no link up
($error == null): Invalid value: false: Expected value: true

Logs

Four runs of this suite, across PRs that touch neither Redis nor the backup controller:

The same suite, the same code, red once out of four. The durations are worth noting: the green runs take 52s and 69-72s, and the red one died at 65s, so the failure sits inside the ordinary spread rather than at some outer edge. Whatever margin the step has over the replica link coming up is thinner than the run-to-run variation.

Additional context

The two attempts in the last row are a rerun of the same job on the same commit, which is as close to a controlled repeat as this lane offers: same image digests, same sandbox recipe, opposite outcome.

Not to be confused with #4218, which was Redis red for an unrelated reason: redis-backup was private in OCIR and every pull 403'd. That one is about image access, and its suite passed in the latest run (redis-2-backup-roundtrip, 288s).

Shape-wise this is a sibling of #3852, where clickhouse misses the endpoint Service after a pod restart: an assertion reading a value that is legitimately in motion.

Checklist

• I have checked the documentation
• I have searched for similar issues
• I have included all required information
• I have provided clear steps to reproduce
• I have included relevant logs