Observed
packages/simulator/src/runtime/harness-adapters.integration.test.ts → "delivers and replies through the real OpenClaw dispatcher" failed once with:
→ timed out waiting for the adapter reply
after 106s, on a machine that was concurrently running nx build. The same case passed in three other runs on the same tree at 33s, 41s, and 63s.
Cause
WAIT_TIMEOUT = Duration.seconds(20) in that file bounds takePeerReply, which waits for the OpenClaw dispatcher's reply to arrive back at the peer. The case's total runtime already varies 33s→63s with machine load, so a 20s bound on one leg inside it is tight rather than generous.
Verified not a regression: the full suite passes on the parent commit and on the branch; the failure did not reproduce.
Fix recipe
Either raise WAIT_TIMEOUT for this suite (the file-level testTimeout is already 600s, so the 20s inner bound is the only thing making it flaky), or scale it from an env var so CI and loaded dev machines can differ. Prefer the former unless someone wants the tight bound as a performance canary — in which case it should say so, because right now it reads as an arbitrary constant.
Found while adding the restart proof in #962.
Observed
packages/simulator/src/runtime/harness-adapters.integration.test.ts→ "delivers and replies through the real OpenClaw dispatcher" failed once with:after 106s, on a machine that was concurrently running
nx build. The same case passed in three other runs on the same tree at 33s, 41s, and 63s.Cause
WAIT_TIMEOUT = Duration.seconds(20)in that file boundstakePeerReply, which waits for the OpenClaw dispatcher's reply to arrive back at the peer. The case's total runtime already varies 33s→63s with machine load, so a 20s bound on one leg inside it is tight rather than generous.Verified not a regression: the full suite passes on the parent commit and on the branch; the failure did not reproduce.
Fix recipe
Either raise
WAIT_TIMEOUTfor this suite (the file-leveltestTimeoutis already 600s, so the 20s inner bound is the only thing making it flaky), or scale it from an env var so CI and loaded dev machines can differ. Prefer the former unless someone wants the tight bound as a performance canary — in which case it should say so, because right now it reads as an arbitrary constant.Found while adding the restart proof in #962.