Repository navigation
chore: two e2e tests flicker, and the deploy gate hangs on the suite they are in #429
Description
Two tests in the browser suite fail about one run in several and pass on a rerun. Taken one at a time each is an annoyance; taken together they are a gate nobody can read any more, because deploy hangs on e2e and whoever reruns on red has abolished the gate.
The two
e2e/contact.spec.ts:542 — "the duration is on the page, and it is what proves a real send". Red once in the second full local run of U8, green in the first. .tx-log li[data-dir='in'] was not there after 5 s: the routed answer did not arrive, or arrived late.
| full run 1 | 2,352 green, 348 skipped, 8.3 min |
| full run 2 | 2,351 green, 1 red, 8.6 min |
contact.spec.ts alone @ w1081 |
37 green, 31 s |
| that one test, three times | 3 × green |
So load, not breakage: eight workers, and every submission waits out the 3,000 ms dwell threshold (ADR 0021 §2). Not touched by U8 — contact.spec.ts is unchanged, lib/contact/* too, and the catalogue strings on /contact are English in this project either way.
e2e/touch-targets.coarse.spec.ts:172 — the second of the same kind, recorded one stage earlier.
Why it is one issue and not two
deploy runs after e2e. A gate that goes red for a reason unrelated to the change in front of it teaches everybody to rerun first and read second, and then it is not a gate. The decision this issue wants is which of the three: make the two tests wait on a condition rather than a timeout, take them out of the gating suite and run them on a schedule, or accept the flicker in writing with a documented rerun rule.
#291 is the neighbour — selftest flickering on witness.sh, about one run in five — and the same question is behind all three. (The backlog pointed at #180 and #181 for this; both are closed.)
Activity
feat(web): the page prose speaks German, and the islands say so (#432)
test(web): the island rule is read in one snapshot (#435)
docs(backlog): the watcher waited for itself, and p95 was stale (#452)
docs(backlog): the tail is thirty seconds minus the twin (#455)
docs(backlog): one read of health is not an identity (#456)
G1NG4R commentedon Oct 17, 2026
A measured rate for the count test, from twelve
e2eruns in one night(2026-10-16 21:45 → 2026-10-17 03:30 UTC), across six PRs and their
mainruns:e2erunstouch-targets.coarse.spec.ts:211failedExpected: 2 · Received: 1at[coarse-390]The three:
mainfor50bd9cc, PR #457, andmainforf0e5998. Each wasgreen on a
gh run rerun --failedwith no code touched.Two of the three were on
main, and theredeployis skipped — so a swapthat was queued did not happen until a human (or a loop) noticed and reran. That
is the "deploy gate hangs on the suite they are in" half of this issue, observed
twice in one night rather than argued about.
Nothing here identifies the mechanism; it is frequency only, the same shape the
note in #291 asks for. What is new is that 25 % over twelve runs is high enough
that a phase closing with
make bundle-sizeand a merge will meet it.Alongside:
e2eduration onmainranged from 12:40 to 38:30 in the samenight, all green, so a long run is not a sign of this failure.