Commit 0929195
committed
Mark WS handshake tests flaky with reruns=2 for slow CI runners
After three rounds of timeout bumps the WS tests still flake on a
subset of GitHub Windows runners — most strikingly the run for
d4083b5 had 3.12 fail all four WS tests in sequence, each waiting
exactly 60 s before timing out. The fact that the recvs ran the
full 60 s budget means the timeout itself is no longer the issue:
the host process is genuinely not delivering data on those runner
instances. 3.10 / 3.13 were clean in the same run, 3.11 / 3.14
had one failure each — pure infrastructure flake, not a
deterministic regression.
Pragmatic fix: add pytest-rerunfailures (industry-standard for
"green locally, flakes on CI" tests) and decorate just the four
WS handshake tests with @pytest.mark.flaky(reruns=2, reruns_delay=1).
Three attempts × 60 s worst-case is still well under the 120 s
per-test pytest-timeout we already set, so a runner glitch on the
first attempt no longer reds the whole matrix.
The 60 s production timeouts shipped earlier stay — they're the
right value for high-latency real users, and revisiting the host's
listener-setup race is a separate (bigger) project.1 parent d4083b5 commit 0929195
2 files changed
Lines changed: 5 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
81 | 81 | | |
82 | 82 | | |
83 | 83 | | |
84 | | - | |
| 84 | + | |
85 | 85 | | |
86 | 86 | | |
87 | 87 | | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
114 | 114 | | |
115 | 115 | | |
116 | 116 | | |
| 117 | + | |
117 | 118 | | |
118 | 119 | | |
119 | 120 | | |
| |||
130 | 131 | | |
131 | 132 | | |
132 | 133 | | |
| 134 | + | |
133 | 135 | | |
134 | 136 | | |
135 | 137 | | |
| |||
143 | 145 | | |
144 | 146 | | |
145 | 147 | | |
| 148 | + | |
146 | 149 | | |
147 | 150 | | |
148 | 151 | | |
| |||
163 | 166 | | |
164 | 167 | | |
165 | 168 | | |
| 169 | + | |
166 | 170 | | |
167 | 171 | | |
168 | 172 | | |
| |||
0 commit comments