-
Notifications
You must be signed in to change notification settings - Fork 2
bug(a2a): message/send responses shifted by one — request N receives response to request N-1 #2326
Description
Problem
After PR #2318 fixed the classifier-401 block (PR #2314) and drained stale LoopbackEvent::Flush events, message/send now returns a non-empty response for the first request, but subsequent requests each receive the previous request's response.
Reproduction (4 sequential /a2a POSTs)
| Request | Query | Expected artifacts | Actual artifacts |
|---|---|---|---|
| 1 | "5+3" | "8" | "8" ✅ |
| 2 | "7*6" | "42" | empty (0) ❌ |
| 3 | "11*11" | "121" | "42" (request 2's answer) ❌ |
| 4 | "capital of France" | "Paris" | "121" (request 3's answer) ❌ |
Analysis
The fix in #2318 drains a stale LoopbackEvent::Flush with try_recv(). However, a systematic one-position shift remains: each request appears to consume the LLM response intended for the previous request, while its own response is left in the channel for the next request to consume.
Likely cause: the drain in #2318 empties the Flush event but the LLM FullMessage response from the previous request is still buffered in output_rx. On the next message/send, the recv_loop immediately picks up this stale FullMessage (which arrives before the new LLM response), builds an artifact from it, and returns — the new response arrives too late and is left for the subsequent request.
Expected
Each message/send should block until its own LLM response arrives and return only that response in artifacts.
Priority
P2 — A2A server is functionally broken for multi-request sessions; single-request sessions work correctly post-#2318.
Discovered in CI-248, 2026-03-28. Confirmed using endpoint /a2a (not /message/send which returns 404).