workflow: pin the spec engine's concurrency — the auto default is one slot on small CI runners

The two tests that wait for two children IN FLIGHT (the pipeline
no-barrier test and the dropped-promise cancellation test) inherited the
engine's auto-resolved maxConcurrentAgents, which is
min(16, max(1, cores - 2)) — exactly 1 on the 2-core CI runner, so the
second child never started and vi.waitFor timed out. Reproduced locally
under taskset -c 0,1; the full spec passes there with the helper pinning
a fixed ceiling. Tests about the ceiling itself keep their explicit
overrides, and the auto-resolve arm stays covered by the
default-config provider tests.
This commit is contained in:
Tianyi Cui
2026-07-06 20:59:47 +08:00
parent a8986c2c8a
commit e70227d581

View File

@@ -97,7 +97,10 @@ async function setup(options?: SetupOptions) {
options?.disposeDelayMs ?? 0,
)
ctx.subagents.registerProvider(provider)
await ctx.plugin(VmWorkflowEngine, { provider: 'stub', ...options?.config })
// A fixed concurrency ceiling: the auto-resolved default is machine-derived
// (cores - 2, floored at 1), so tests that expect N children in flight
// would wedge on small CI runners. Tests about the ceiling override it.
await ctx.plugin(VmWorkflowEngine, { provider: 'stub', maxConcurrentAgents: 8, ...options?.config })
return { ctx, provider, parent: fakeParent() }
}