Phase 2: SSE chat_completion times out client-side on response delivery

[Alajmah]

Summary

chat_completion over the MCP/SSE transport times out client-side (~120s) even though the request reaches Chrome successfully and the reply is generated. This blocks Phase 2's goal of making SSE the recommended ZCode transport.

Tracked in docs/ROADMAP.md under Phase 2 — Known follow-up (discovered during Phase 0 verification, 2026-06-25).

Reproduction

Transport config (client side):

{ "chatgpt-web2api-sse": { "type": "sse", "url": "http://localhost:8090/sse" } }

Observed sequence (2026-06-25):

• initialize → OK
• tools/list → OK (9 tools)
• list_models → OK (1034 bytes returned)
• chat_completion → times out client-side at 120s

Server-side, the send did reach Chrome: the reply appeared in the account (conversation titled with the requested marker string). The equivalent REST chat path returns the same kind of generation in ~2s.

Expected behavior

chat_completion over SSE returns the generation within the same order of magnitude as the REST path (seconds, not a timeout).

Scope

This is a Phase 2 transport bug, not a regression from PR #9 (composer redesign / Phase-2 non-text / tab isolation, merged as 9ebb236). Short SSE tools work; only the long-running chat_completion response delivery fails.

Debug hypotheses to check

Ordered roughly cheapest-to-rule-out first:

• Progress notifications blocking the response stream
• Async generator never completing (completion detection not firing over SSE path)
• MCP response never posted to /messages
• uvicorn/starlette SSE flush / backpressure (buffered chunks not flushed)
• Long-running tool timeout mismatch (client vs server deadline)

Acceptance criteria

• chat_completion over SSE returns the generation client-side
• Integration test added per ROADMAP Phase 2 (initialize → tools/list → list_models → one chat call → repeated fresh connections)
• No tab/process growth across repeated fresh SSE connections

[Alajmah]

Root-cause diagnosis (instrumented reproduction, 2026-06-25)

Instrumented the full chat_completion path with 6 boundary markers (B1–B6) plus a per-poll DOM-state trace, then reproduced against a live SSE server (--log-level DEBUG) with Chrome confirmed healthy and REST returning the same generation in ~2s.

Confirmed: NOT a transport/SSE delivery bug

The transport layer is exonerated. Every boundary up to Chrome fired correctly:

[B1] call_tool received name=chat_completion args_keys=['message']      ✓ request reached handler
[B2] entering send_and_stream on_progress=False                          ✓ Chrome send started
     (progress callback is None — client sent no progressToken. Progress
      notifications are NOT a factor in this hang.)
[B6] /messages POST for chat_completion: entered, never completed         ✓ POST open, waiting for handler

The client times out at 30–120s while the handler is still inside send_and_stream. The transport never gets a chance to deliver — there's nothing to deliver yet.

The hang: completion detection deadlocks for the full 120s deadline

The completion poll loop ran 116s+ with zero DOM change and only exited on the while time.monotonic() < deadline clause:

[POLL] + 5.0s  has_action=False is_thinking=True  md_len=0  text_len=0  html_len=253 child=1 stall_in=89.5s conv=
[POLL] +10.1s  ...identical...
[POLL] +116.9s ...identical...
[B4] handler returned content_len=12 conv_id=6a3cbad8-...                ✓ eventually returned, at the deadline

The generated content was correct (SSE_TRACE_OK, verified via REST follow-up) — Chrome finished the answer in ~2s, but the driver didn't detect completion for ~120s.

Three compounding failures (all in cdp_driver.py:send_and_stream)

1. is_thinking=True freezes the stall detector. The DOM shows a persistent reasoning placeholder (.result-thinking lingers). The poll loop's thinking branch (cdp_driver.py:1787) does last_change_time = time.monotonic() every iteration regardless of whether anything actually changed. So time.monotonic() - last_change_time > PHASE_STALL_SECONDS is never true → the 90s stall guard never fires, and the trace shows stall_in=89.5s frozen for 116s+.

2. has_action (primary completion signal) never becomes true. The action-button selector (*-turn-action-button, with 4-ancestor walk + 240px geometry gate) didn't match on the SSE tab's DOM during this generation. Either the selector drifted again or the geometry/descendant gate is too strict for the current layout. (The comment block at cdp_driver.py:1700-1716 notes this selector has already drifted twice.)

3. Backend end_turn fallback is dead on new conversations. The secondary completion signal (cdp_driver.py:1822-1847) is gated by conv_id_for_check and .... But conv_id_for_check is captured once before the loop from self._current_conv_id (cdp_driver.py:1675), which is None on a fresh chat — it's only resolved from the URL after the loop (cdp_driver.py:1854+, "Wait for URL to become /c/{id}"). So the one signal that could have broken the deadlock is disabled for the entire generation. Trace confirms conv= (empty) throughout.

Why REST works but SSE doesn't

Both use the same send_and_stream. The difference is conversation state:

• REST (api_server.py) is a long-running server that keeps _current_conv_id populated across requests, so the backend end_turn fallback is live.
• SSE (mcp_server.py) drives fresh navigate_new_chat sends where _current_conv_id is None at loop entry, disabling the fallback.

The DOM signals (#1, #2) fail in both; only the backend fallback (#3) distinguishes them, and it's off for SSE's common case.

No behavior changed yet

This is diagnosis only. No fix applied. The instrumentation (boundary markers + poll trace) is in the working tree, uncommitted.

Fix directions (for review — not implemented)

Three independent options, in increasing scope:

1. Resolve conv_id inside the loop, not before it. Poll window.location.href for /c/{id} and update conv_id_for_check mid-loop so the backend end_turn fallback is live for new conversations. Smallest change, directly unblocks signal fix(foundation): systematic audit — 24 bugs fixed across 5 phases #3.

2. Make is_thinking stop resetting the stall clock unconditionally. Track a separate thinking-start time; cap the thinking-reset at a max duration (e.g. PHASE_STALL_SECONDS) so a frozen .result-thinking doesn't defeat the stall detector. Fixes 🔧 [GitWire] Fix: resolve lint error in pyproject.toml #1.

3. Repair/relax the has_action selector. Revisit the 4-ancestor + 240px geometry gate against the current ChatGPT DOM. Fixes fix: address all deep dive review findings (10 fixes) #2, the primary signal — but this has drifted twice before and is the most fragile.

Option 1 is the highest-leverage / lowest-risk: it restores the one signal that already worked for REST and needs no DOM-selector changes. Recommend starting there and re-measuring before touching the DOM heuristics.