Aleksei Sviridkin 4878250a1d fix(e2e): wait for the redis replica link instead of sampling it once ...

The redis-tls topology check read INFO replication from both pods once
and failed the suite when a replica reported role:slave without
master_link_status:up. That value is legitimately in motion there.
Redis reports the link up only in REPL_STATE_CONNECTED, while the
operator's readiness script admits a replica on two different
predicates -- master_host off 127.0.0.1, and sync not in the transfer
phase -- so every handshake state between the two is ready and
unlinked, and a dropped link re-enters that window. Ready replicas
carry no evidence about the link at all, which is more than the step's
own comment allowed for and makes its claim of determinism wrong.

Poll the topology to a 60s deadline instead, and on expiry report each
pod's observed state along with how long it waited. Nothing models the
link declaratively -- the RedisFailover CRD defines no status, so there
is no condition to assert on and the poll carries the marker the e2e
conventions require.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>

2026-09-14 23:37:54 +03:00

..

chainsaw-test.yaml

fix(e2e): wait for the redis replica link instead of sampling it once

2026-09-14 23:37:54 +03:00

redis-flip-tls.yaml

test(redis): exercise TLS end to end in the chainsaw suite

2026-09-02 17:58:06 +03:00

redis-flip.yaml

test(redis): exercise TLS end to end in the chainsaw suite

2026-09-02 17:58:06 +03:00

redis-tls.yaml

test(redis): exercise TLS end to end in the chainsaw suite

2026-09-02 17:58:06 +03:00

redis.yaml

test(e2e): migrate app suite from BATS to Chainsaw and wire into CI

2026-06-25 13:42:34 +05:00