Problem
Following the same failure class as #4383 (fixed for packages/runtime in #4387): several packages/runtime-host test helpers poll for an asynchronous condition with a fixed count of macrotask ticks instead of a wall-clock deadline. The tick count is not a time budget — under a loaded CI runner the underlying work (turn settlement over UDS connections, agent-graph wake-run persistence, peer mesh roster propagation, provider request capture persistence) can span more ticks than the loop allows, so the helper gives up before the condition is genuinely false and the test reports a failure that cannot be distinguished from a real regression.
Inventory
Fixed-tick polling loops in packages/runtime-host/src/__tests__:
execution-model-composition.test.ts — the graph-wake loop (400 ticks), startTurn (200), waitForTerminal (200), waitForUsage (100), waitForCanonicalAttempts (100), waitForCaptureArtifacts (100), waitForAutomaticMemoryRequestsToSettle (100)plan-two-client-uds.test.ts — waitForTerminal (100), polling turn.query over a real UDS connectionruntime-policy-coordinator.test.ts — inline turn-settlement loop (100 × 20ms)peer-mesh.test.ts — roster propagation loop (20 × 10ms; a 200ms budget over real serve/join networking)peer-native.test.ts — waitForRequestCount (10 immediates)
The in-memory setImmediate helpers (waitForPending in client-capability-admission-integration.test.ts, waitForGoalRun in goal-root-authority.test.ts) are intentionally out of scope: they poll in-memory facades where a tick budget is effectively unbounded.
Desired outcome
Convert the listed loops to the shared waitFor primitive from @maka/core/test-only/async-primitives with an explicit wall-clock deadline (5s) and a small poll interval, keeping each helper's failure message. Production behavior is unchanged; this is test-infrastructure only.
Automated disclosure: this issue was drafted by Claude at @qianzhu18's direction. @qianzhu18 remains the human contributor of record.
Problem
Following the same failure class as #4383 (fixed for
packages/runtimein #4387): severalpackages/runtime-hosttest helpers poll for an asynchronous condition with a fixed count of macrotask ticks instead of a wall-clock deadline. The tick count is not a time budget — under a loaded CI runner the underlying work (turn settlement over UDS connections, agent-graph wake-run persistence, peer mesh roster propagation, provider request capture persistence) can span more ticks than the loop allows, so the helper gives up before the condition is genuinely false and the test reports a failure that cannot be distinguished from a real regression.Inventory
Fixed-tick polling loops in
packages/runtime-host/src/__tests__:execution-model-composition.test.ts— the graph-wake loop (400 ticks),startTurn(200),waitForTerminal(200),waitForUsage(100),waitForCanonicalAttempts(100),waitForCaptureArtifacts(100),waitForAutomaticMemoryRequestsToSettle(100)plan-two-client-uds.test.ts—waitForTerminal(100), pollingturn.queryover a real UDS connectionruntime-policy-coordinator.test.ts— inline turn-settlement loop (100 × 20ms)peer-mesh.test.ts— roster propagation loop (20 × 10ms; a 200ms budget over real serve/join networking)peer-native.test.ts—waitForRequestCount(10 immediates)The in-memory
setImmediatehelpers (waitForPendinginclient-capability-admission-integration.test.ts,waitForGoalRuningoal-root-authority.test.ts) are intentionally out of scope: they poll in-memory facades where a tick budget is effectively unbounded.Desired outcome
Convert the listed loops to the shared
waitForprimitive from@maka/core/test-only/async-primitiveswith an explicit wall-clock deadline (5s) and a small poll interval, keeping each helper's failure message. Production behavior is unchanged; this is test-infrastructure only.Automated disclosure: this issue was drafted by Claude at @qianzhu18's direction. @qianzhu18 remains the human contributor of record.