Browse Source

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.
Tianyi Cui 3 months ago
parent
commit
e70227d581
1 changed files with 4 additions and 1 deletions
  1. 4 1
      packages/workflow/workflow-vm/tests/workflow-vm.spec.ts

+ 4 - 1
packages/workflow/workflow-vm/tests/workflow-vm.spec.ts

@@ -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() }
 }