Problem
After pressing Stop on an ACP chat turn, Thunderbolt already sends session/cancel and frees the local UI stream. Some ACP agents only release the session busy slot when the cancelled turn fully exits. Sending another message quickly can then fail with:
Session already has an active prompt turn: <sessionId>
Chat auto-retry can hit the same error again and make the session feel stuck.
Expected
Stop → send (after the prior prompt has settled on the wire) should not race a second session/prompt onto a still-busy session. SESSION_BUSY / "active prompt turn" should not be blind-auto-retried.
Proposed fix
See #1093:
- Await in-flight
connection.prompt settle per session before the next prompt
- Treat "active prompt turn" as non-retryable in chat auto-retry
Notes
Reproduced against a local Zeroclaw ACP gateway; the client-side race is general for agents with cancel-then-still-busy semantics.
Problem
After pressing Stop on an ACP chat turn, Thunderbolt already sends
session/canceland frees the local UI stream. Some ACP agents only release the session busy slot when the cancelled turn fully exits. Sending another message quickly can then fail with:Session already has an active prompt turn: <sessionId>Chat auto-retry can hit the same error again and make the session feel stuck.
Expected
Stop → send (after the prior prompt has settled on the wire) should not race a second
session/promptonto a still-busy session. SESSION_BUSY / "active prompt turn" should not be blind-auto-retried.Proposed fix
See #1093:
connection.promptsettle per session before the next promptNotes
Reproduced against a local Zeroclaw ACP gateway; the client-side race is general for agents with cancel-then-still-busy semantics.