From e9ce56e8386100a93e4fc5178f5e3ba13462cb04 Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 23 Oct 2026 14:58:14 +0200 Subject: [PATCH] Say in the test why the waits are 20 s: load, not a retry (issue 1404) --- .../mesh-delivery-gate/cmd/mesh-delivery-gate/bus_test.go | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/modules/mesh-delivery-gate/cmd/mesh-delivery-gate/bus_test.go b/modules/mesh-delivery-gate/cmd/mesh-delivery-gate/bus_test.go index c1458d38..77bc463a 100644 --- a/modules/mesh-delivery-gate/cmd/mesh-delivery-gate/bus_test.go +++ b/modules/mesh-delivery-gate/cmd/mesh-delivery-gate/bus_test.go @@ -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