Support asynchronous commands for custom ACP providers - #3369
Conversation
Generic ACP adapters can now opt into the existing initial-command wait through durable provider params, and ACP input hints survive translation into Paseo autocomplete entries. Constraint: Some ACP agents publish available_commands_update only after session/new returns. Rejected: Special-case the zcode provider name | leaves other asynchronous custom ACP adapters exposed to the same race. Confidence: high Scope-risk: narrow Directive: Keep waiting opt-in for generic providers that never publish command updates. Tested: targeted Vitest; server build; monorepo typecheck; targeted lint and format; isolated Paseo 0.4 daemon returned 78 GLM-5.3 draft commands with argument hints. Not-tested: production daemon restart deferred because an unrelated Claude agent is running.
|
| Filename | Overview |
|---|---|
| packages/server/src/server/agent/providers/generic-acp-agent.ts | Adds validated provider parameters and applies explicit client-option precedence when forwarding initial-command wait settings. |
| packages/server/src/server/agent/providers/acp-agent.ts | Preserves optional ACP command input hints when translating command updates into autocomplete entries. |
| packages/server/src/server/agent/providers/generic-acp-agent.test.ts | Covers option forwarding but asserts mocked superclass internals instead of observable command-listing behavior. |
| packages/server/src/server/agent/providers/acp-agent.test.ts | Extends asynchronous command-update coverage to verify that input hints are preserved. |
| docs/custom-providers.md | Documents how custom ACP providers opt into bounded waiting for asynchronously published commands. |
Sequence Diagram
sequenceDiagram
participant Config as Provider config
participant Client as GenericACPAgentClient
participant Session as ACPAgentSession
participant Provider as ACP provider
participant Composer as New-agent composer
Config->>Client: waitForInitialCommands + timeout
Client->>Session: create session with wait options
Session->>Provider: session/new
Composer->>Session: listCommands()
Session->>Session: wait for initial update or timeout
Provider-->>Session: available_commands_update
Session-->>Composer: commands with argument hints
Reviews (1): Last reviewed commit: "Let custom ACP providers publish command..." | Re-trigger Greptile
|
|
||
| test("uses provider params to wait for asynchronously published slash commands", () => { | ||
| const _client = new GenericACPAgentClient({ | ||
| logger: createTestLogger(), | ||
| command: ["zcode-acp-server"], | ||
| providerParams: { | ||
| waitForInitialCommands: true, | ||
| initialCommandsWaitTimeoutMs: 2_000, | ||
| }, | ||
| }); | ||
| void _client; | ||
|
|
||
| expect(mockState.superConstructorOptions.at(-1)).toMatchObject({ | ||
| waitForInitialCommands: true, |
There was a problem hiding this comment.
Test asserts constructor internals
This test only inspects captured ACPAgentClient constructor options instead of creating a session and observing listCommands(), coupling coverage to implementation details without verifying that provider parameters produce the caller-facing asynchronous-command behavior.
Rule Used: # Code Review Pattern Reference: Slop, Tests, Feat... (source)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Summary
available_commands_updateaftersession/newProblem
Generic ACP draft sessions call
listCommands()immediately aftersession/new. Providers such aszcode-acp-serverpublish commands asynchronously, so the new-agent composer can cache an empty list. The same timing class already has provider-specific handling for Cursor, Trae, and Kiro.Verification
npx vitest run packages/server/src/server/agent/providers/generic-acp-agent.test.ts --bail=1npm run build:servernpm run typecheckConfiguration