A thread blocked on AskUserQuestion rejects incoming messages with 409. The refusal itself is defensible — the problem is that only the sender learns about it, so the recipient's inbox silently loses messages it will never know existed.
Verbatim, both directions
Sending to a blocked thread:
thr_xaisx58uif: HTTP 409: Thread is awaiting user interaction.
Resolve the pending interaction before sending another prompt.
Receiving while blocked — the damaging direction. An orchestrator held an AskUserQuestion open; a worker sent it three substantive reports:
wake failures: thr_xqcw2v38e4: HTTP 409: Thread is awaiting user interaction.
All three were stored in the bus room (#2780, #2781, #2783). None was delivered.
The consequence was not hypothetical:
- the worker believed it had reported
- the orchestrator believed the worker had gone silent for 3.5 hours, and accused it of stalling
On recovery, a local watchdog reconstructed what had happened:
3 bus message(s) addressed to you were never delivered
(sent while you were blocked - the sender saw success)
The defect is the asymmetry, not the refusal
The system knows the delivery did not land. It tells the sender and says nothing to the recipient. An unreachable inbox is therefore indistinguishable from a peer that simply had nothing to say — which is exactly the wrong inference for an orchestrator to be forced into.
The ask is not "make 409 go away"
Either would fix it:
- Queue the message and deliver it when the pending interaction resolves, or
- Let the blocked thread see that something was addressed to it — even a count on unblock would have prevented the 3.5-hour misread
Note on how this was gathered
Every record above is incidental, from real multi-agent work. Deliberately manufacturing the blocked state to test it parks a thread in a human's attention queue and rings their machine, so it was not done.
Separately and more narrowly: threads that end in status=error appear to produce no completion notification at all. That is a different gap and not part of this report. Threads that complete normally do notify — an earlier version of this claim said otherwise and was wrong; three controlled trials on 0.37.0 produced a completed notification every time.
A thread blocked on
AskUserQuestionrejects incoming messages with 409. The refusal itself is defensible — the problem is that only the sender learns about it, so the recipient's inbox silently loses messages it will never know existed.Verbatim, both directions
Sending to a blocked thread:
Receiving while blocked — the damaging direction. An orchestrator held an
AskUserQuestionopen; a worker sent it three substantive reports:All three were stored in the bus room (#2780, #2781, #2783). None was delivered.
The consequence was not hypothetical:
On recovery, a local watchdog reconstructed what had happened:
The defect is the asymmetry, not the refusal
The system knows the delivery did not land. It tells the sender and says nothing to the recipient. An unreachable inbox is therefore indistinguishable from a peer that simply had nothing to say — which is exactly the wrong inference for an orchestrator to be forced into.
The ask is not "make 409 go away"
Either would fix it:
Note on how this was gathered
Every record above is incidental, from real multi-agent work. Deliberately manufacturing the blocked state to test it parks a thread in a human's attention queue and rings their machine, so it was not done.
Separately and more narrowly: threads that end in
status=errorappear to produce no completion notification at all. That is a different gap and not part of this report. Threads that complete normally do notify — an earlier version of this claim said otherwise and was wrong; three controlled trials on 0.37.0 produced acompletednotification every time.