Say in the test why the waits are 20 s: load, not a retry (issue 1404)
mesh/delivery-group group feat/fastcheck checking: composed check out of date: novox/mesh-catalog@e9ce56e83861 was judged against trunk 89e15c7bcda6, the trunk…
mesh/delivery delivering: 0 machine step(s) passed
mesh/check checking e9ce56e83861 on e21ccf113842 | novox/mesh-catalog#460 in group feat/fastcheck

This commit is contained in:
2026-10-23 14:58:14 +02:00
parent ee176b76ea
commit e9ce56e838
@@ -944,8 +944,7 @@ func mustDecode[T any](t *testing.T, raw []byte) T {
}
// eventWithin is how long a test waits for one step of the gate's path over the real bus. On an idle machine each step
// takes milliseconds (the tests log it), but the build node runs the whole group's checks at once, and a step that
// fails its first try (a key rewritten under it, a request that timed out) is tried again by the gate only after
// retryFirst (10 s, effects.go), which the test cannot shorten without changing production code. 20 s covers that one
// retry plus the load; "within seconds" stays true and a stuck path still fails (issue 1404).
// takes milliseconds (the tests log it), but a slow, loaded build node ran the ask step in 6.69 s against the old 5 s
// (issue 1404). A failed first ask is asked again only after askAgainAfter (30 s, react.go), and 20 s deliberately does not
// cover that: a failed first ask still fails the test.
const eventWithin = 20 * time.Second