From 6593f06213697b96c9a9f499e5a05b2abf591d45 Mon Sep 17 00:00:00 2001 From: Relayflow Lead Date: Sat, 29 Aug 2026 19:03:47 -0400 Subject: [PATCH] =?UTF-8?q?fix:=20raise=20the=20vitest=20timeout=20?= =?UTF-8?q?=E2=80=94=20the=20sandbox=20is=20slower=20than=20a=20laptop?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Run ae982aaa reported 22 failed / 166 passed and was marked VERIFY_FAIL_NONFATAL. The same commit runs 188/188 clean locally. Nearly every failure in the run log is 'Test timed out in 5000ms' — vitest's default, which is comfortable on a laptop and too tight in a cloud sandbox. The cost is not just noise. A failing verify marks the run failed, and it then commits and opens a PR anyway, so work that is actually fine arrives labelled broken — PR #43 is exactly that: its branch is 188/188 green here. 30s is still short enough to catch a genuine hang, and cases that legitimately need longer already declare it themselves (live-kernel uses 45s). Verified locally: sdk 186 passed across 13 files in 39s. NOT proven in a sandbox — inferred from the run log's timeout messages. The check is whether the next run's verify stops reporting timeout failures. Co-Authored-By: Claude Fable 5 --- sdk/vitest.config.ts | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/sdk/vitest.config.ts b/sdk/vitest.config.ts index efa710b6..c10f2ad4 100644 --- a/sdk/vitest.config.ts +++ b/sdk/vitest.config.ts @@ -5,5 +5,16 @@ export default defineConfig({ environment: 'node', include: ['tests/**/*.test.ts'], globals: false, + // vitest defaults to 5s per test. That is fine on a laptop and too tight in + // a cloud sandbox: run ae982aaa reported 22 failed / 166 passed, almost all + // of them 'Test timed out in 5000ms', while the same commit runs 188/188 + // clean locally. Those phantom failures are expensive — they fail verify, + // which marks the run VERIFY_FAIL_NONFATAL, and it then commits and opens a + // PR carrying work that is actually fine but labelled broken. + // + // 30s is still short enough to catch a genuine hang. Cases that legitimately + // need longer already declare it themselves (live-kernel uses 45s). + testTimeout: 30_000, + hookTimeout: 30_000, }, });