test(code-runtime): widen the idle-budget timing margin

The slow-binding test used a 250 ms compute budget, which is below the instrumented worker startup cost seen intermittently in the four-worker Windows coverage job. That startup activity could exhaust the budget before the program settled into the awaited binding, making the timing assertion depend on runner load. Use a one-second compute budget and a two-second binding delay. The awaited wall time still exceeds the busy-time allowance by a clear factor, so the test continues to prove that binding wait time is not charged while leaving enough headroom for worker initialization under coverage.
2026-07-19 14:30:46 +08:00
parent f6f984de06
commit 0c1bc50b98
1 changed files with 2 additions and 2 deletions
@@ -129,10 +129,10 @@ describe('WorkerCodeRuntime — budgets and containment (real workers)', () => {
  }, 15_000)

  it('does not charge time spent awaiting a slow binding against the compute budget', async () => {
-    const { runtime } = await setup({ computeMs: 250, maxWallMs: 30_000 })
+    const { runtime } = await setup({ computeMs: 1_000, maxWallMs: 30_000 })
    const result = await runtime.run({
      program: 'return await tools.slow({})',
-      bindings: tools({ slow: () => new Promise(resolve => setTimeout(() => { resolve('slow-done') }, 700)) }),
+      bindings: tools({ slow: () => new Promise(resolve => setTimeout(() => { resolve('slow-done') }, 2_000)) }),
    })
    expect(result.error).toBeUndefined()
    expect(result.value).toBe('slow-done')