test: the netns scenarios wait out a slow answer on the lossy link (keel#94) #128

Merged

marcos-mendez merged 3 commits from test/flaky-netns-94 into main

2026-10-09 14:23:58 -03:00

marcos-mendez commented

2026-10-09 13:24:54 -03:00

(Migrated from github.com)

Closes #94.

What

The mesh driver's ping right after a join repeats until the confirmation window (120 s), not only three rounds: a lost WireGuard initiation is sent again after the 5 s rekey, and on the poor link (250 ms, 2% loss) the first handshake can take that long. This is the test_c_joins_through_the_fallback flake.
The vip-upgrade driver's upgrade-check after C's etcd restarted is asked again, bounded at 90 s, until every endpoint is healthy, instead of one call on a member that is seconds old.
The vip driver's planned promote runs three times between A and B; the test judges the median downtime, not one attempt over the lossy link. B holds the VIP again at the end, as (c) needs; stale uses relative epochs, so the two extra promotes do not change (e) or (g).
The mariadb driver's boot follow (the k104 block) is repeated, bounded at 120 s, while A's etcd is too new to answer; the failure is at the observation, before anything changes. The test accepts the two legitimate boot outcomes: the unproven-claim line, or the replica path when the newer claim reached A first. Both leave it read only, and the never-writable property stays judged by the boot-to-rejoin samples; the unit tests of the unproven path are unchanged.

What is not changed

The measured-link check (test_the_links_are_the_design_case) stays strict.
No product code; no changelog entry (tests only).

Test plan

CI: mesh / trixie, vip / trixie, vip-upgrade / trixie, mariadb / trixie green

Closes #94. ## What - The mesh driver's ping right after a join repeats until the confirmation window (120 s), not only three rounds: a lost WireGuard initiation is sent again after the 5 s rekey, and on the poor link (250 ms, 2% loss) the first handshake can take that long. This is the `test_c_joins_through_the_fallback` flake. - The vip-upgrade driver's `upgrade-check` after C's etcd restarted is asked again, bounded at 90 s, until every endpoint is healthy, instead of one call on a member that is seconds old. - The vip driver's planned promote runs three times between A and B; the test judges the median downtime, not one attempt over the lossy link. B holds the VIP again at the end, as (c) needs; `stale` uses relative epochs, so the two extra promotes do not change (e) or (g). - The mariadb driver's boot follow (the k104 block) is repeated, bounded at 120 s, while A's etcd is too new to answer; the failure is at the observation, before anything changes. The test accepts the two legitimate boot outcomes: the unproven-claim line, or the replica path when the newer claim reached A first. Both leave it read only, and the never-writable property stays judged by the boot-to-rejoin samples; the unit tests of the unproven path are unchanged. ## What is not changed - The measured-link check (`test_the_links_are_the_design_case`) stays strict. - No product code; no changelog entry (tests only). ## Test plan - [ ] CI: mesh / trixie, vip / trixie, vip-upgrade / trixie, mariadb / trixie green