mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-04-28 03:30:40 +00:00
* fix(cli): run ACP Agent tool calls concurrently (#2516)
When the model returns multiple Agent tool calls in a single turn, the
ACP Session previously executed them sequentially in a plain for-loop,
multiplying latency by the number of sub-agents spawned.
Mirror the partition logic in coreToolScheduler.partitionToolCalls:
consecutive Agent calls form a parallel batch (safe because sub-agents
have no shared mutable state); any other tool forms its own sequential
batch so the model's implicit ordering is preserved. Response-part
ordering still matches the original functionCalls order.
Add a focused test that uses controllable deferred executes to prove
both Agent calls start before either resolves, and that the fed-back
functionResponse ordering is stable regardless of resolution order.
* Address PR #3463 review: bound concurrency + robust test timing
Two issues raised by the /review bot:
1. The raw Promise.all fan-out bypassed the bounded-concurrency guard
that coreToolScheduler applies via QWEN_CODE_MAX_TOOL_CONCURRENCY.
Replaced with an inline runBounded helper that mirrors core's
runConcurrently (Promise.race on a bounded executing set, default
cap 10), keeping in-order result collection.
2. The concurrency test used a 10-iteration microtask yield loop before
asserting both execute() spies had been invoked. That's fragile —
runTool's pre-execute path (build → getDefaultPermission →
evaluatePermissionRules → permission branch → PreToolUseHook) has
more await boundaries than 10 ticks guarantees, and the CI run
reported call-a still at 0 invocations at the assertion point.
Reworked the test to wait on an explicit `called` deferred that
resolves *inside* the execute() mock body. Under sequential
behaviour only one `called` would ever fire → `Promise.all([called-a,
called-b])` deadlocks → vitest's per-test timeout surfaces the
regression. Under the fix both fire before either result resolves.
* fix(acp): degrade gracefully when AgentTool invocation has no eventEmitter
The concurrency test for #2516 timed out on CI with "Test timed out in
5000ms" after the `await Promise.all([called-a, called-b])` rewrite in
the previous review-fix commit. The 5000ms wait was the symptom; the
root cause is that neither `execute()` was ever being called.
runTool's AgentTool branch was guarded with `'eventEmitter' in invocation`,
which is a *key-presence* check. The test mock provides
`{ eventEmitter: undefined, ... }` — the key exists (value undefined),
the branch is entered, and `SubAgentTracker.setup` immediately throws
inside `eventEmitter.on(...)`. The try/catch in runTool swallows the
throw and returns an error response, so `invocation.execute()` never
runs, `called[id].resolve()` never fires, and the test deadlocks.
The earlier review commit (
|
||
|---|---|---|
| .. | ||
| channels | ||
| cli | ||
| core | ||
| sdk-java | ||
| sdk-typescript | ||
| vscode-ide-companion | ||
| web-templates | ||
| webui | ||
| zed-extension | ||