Leaving a session while a turn is running leaves its response stream open. Nothing cancels the read, so the connection is held until the server ends it, and every session left this way adds another.
The stream is deliberately not aborted, because tearing down the request body would end a live run on the path where this client is the one carrying it. That was the right call for the run, but it means the reader's lifetime is unbounded and is not tied to anything.
There is one behavioural consequence beyond the held connection. A stream that is still being read can report that a send failed, long after the mount that started it is gone, and a runner-to-service disconnect before the admission frames arrive looks exactly like a refusal even though the session-owned runner carries on and persists the message. The user is then told a delivered message was not sent.
Where it shows
- Open the agent chat, send a message on a queue-capable session, and leave the session view while the turn is streaming.
- The invoke request stays open. Repeat, and they accumulate.
What to do
The reader needs an owner and an end. Either hand it to something that outlives the mount and can close it when the run really ends, or keep it on the mount and abort it there on the path where aborting cannot kill the run.
#6658 stopped this stream from writing anything after its mount is gone, by gating every adoption and persistence write on a mount generation. What it did not do is end the read.
Follow-up from #6658. Related: #6696, #6698.
Leaving a session while a turn is running leaves its response stream open. Nothing cancels the read, so the connection is held until the server ends it, and every session left this way adds another.
The stream is deliberately not aborted, because tearing down the request body would end a live run on the path where this client is the one carrying it. That was the right call for the run, but it means the reader's lifetime is unbounded and is not tied to anything.
There is one behavioural consequence beyond the held connection. A stream that is still being read can report that a send failed, long after the mount that started it is gone, and a runner-to-service disconnect before the admission frames arrive looks exactly like a refusal even though the session-owned runner carries on and persists the message. The user is then told a delivered message was not sent.
Where it shows
What to do
The reader needs an owner and an end. Either hand it to something that outlives the mount and can close it when the run really ends, or keep it on the mount and abort it there on the path where aborting cannot kill the run.
#6658 stopped this stream from writing anything after its mount is gone, by gating every adoption and persistence write on a mount generation. What it did not do is end the read.
Follow-up from #6658. Related: #6696, #6698.