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
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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user