Summary
With two tabs viewing an ongoing answer over HTTP/1.1, the Stop request can remain queued while the browser's connections are occupied by SSE streams.
Closing the other tab releases connections and allows Stop to complete. The same scenario works over HTTP/2 with both tabs open.
Steps to reproduce
- Access the application over HTTP/1.1.
- Open two tabs in the same browser profile and sign in with the same account.
- In tab A, ask or retry a question and keep the answer generating.
- In tab B, open the same conversation and confirm that it has reattached to the ongoing answer.
- Click Stop in tab B while keeping both tabs open.
- If Stop remains pending, close tab A.
Expected behavior
Stop reaches the server and stops the answer while both tabs remain open. The partial answer is saved once.
Observed behavior
- Six active SSE responses were observed: each tab had an alerts stream, a knowledge-base events stream, and a chat stream.
- After clicking Stop, its request had no response for more than three seconds.
- Closing tab A allowed Stop to return
200 {"ok":true} within 46 ms in this run.
- Tab B then displayed Stopped, and the partial answer was saved.
- Through an HTTP/2 proxy, Stop completed with both tabs open.
The timing above is one measurement, not a fixed timeout.
Verification environment
- Windows, Chromium 140.0.7339.16, headless, without custom connection-limit arguments.
- Commit
44719a2 in Floating-Y/utopia, based on upstream 798fb24.
- Real Rust server and PostgreSQL database.
- A controlled local model endpoint kept generation active; the chat, reattachment, and Stop APIs were not mocked.
The notification subscriptions and Stop request logic are unchanged by that follow-up patch. This reproduction has not been rerun on an unmodified upstream checkout.
Likely cause
The two tabs occupy the browser's six HTTP/1.1 connections with long-lived streams, leaving no connection available for the separate Stop POST.
This matches the documented multi-tab SSE connection limit:
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
Evidence
utopia-followups-http1-evidence-current.json
Summary
With two tabs viewing an ongoing answer over HTTP/1.1, the Stop request can remain queued while the browser's connections are occupied by SSE streams.
Closing the other tab releases connections and allows Stop to complete. The same scenario works over HTTP/2 with both tabs open.
Steps to reproduce
Expected behavior
Stop reaches the server and stops the answer while both tabs remain open. The partial answer is saved once.
Observed behavior
200 {"ok":true}within 46 ms in this run.The timing above is one measurement, not a fixed timeout.
Verification environment
44719a2in Floating-Y/utopia, based on upstream798fb24.The notification subscriptions and Stop request logic are unchanged by that follow-up patch. This reproduction has not been rerun on an unmodified upstream checkout.
Likely cause
The two tabs occupy the browser's six HTTP/1.1 connections with long-lived streams, leaving no connection available for the separate Stop POST.
This matches the documented multi-tab SSE connection limit:
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
Evidence
utopia-followups-http1-evidence-current.json