[Web] Connection-lost fallback can end in message-send timeout without exposing turn state

What issue are you seeing?

In ChatGPT Web, some submitted messages immediately entered a connection-loss fallback and then ended in a message-send timeout without ever displaying a final answer.

The observed sequence was:

1. Submit a message.
2. The UI immediately displays Connection lost. Waiting for the full response.
3. No incremental response text appears.
4. No final answer arrives.
5. The turn eventually displays a message-send timeout.

The UI does not indicate whether the prompt was accepted, whether a server-side turn still exists, whether the client is reconnecting to that turn, or whether retrying will submit a duplicate prompt.

This report is limited to the observed failure and recovery semantics. It does not attribute the failure to an account, subscription tier, quota, model, or routing cohort.

What steps can reproduce the bug?

1. Open an ordinary Chat conversation on chatgpt.com.
2. Submit a message.
3. If the connection-loss fallback appears, wait for the promised full response rather than resubmitting.
4. Observe whether a final answer is delivered or the turn ends in a message-send timeout.

Observed result:

• the connection-loss fallback appeared immediately after submission;
• the UI said it was waiting for the full response;
• some affected turns never displayed a final answer;
• the flow ended in a message-send timeout;
• the UI did not reveal whether retrying would reconnect to the existing turn or create another one.

The timeout and fallback screens were captured in screenshots from the persisted conversation.

What is the expected behavior?

• Distinguish prompt-submission failure from live-stream failure and final-response retrieval failure.
• If the prompt was accepted, state that the turn is still running and warn against duplicate resubmission.
• Preserve and retrieve the final answer after a temporary stream disconnect whenever the server-side turn completes.
• Present Reconnect to this turn and Resend prompt as distinct recovery actions.
• If the prompt was never accepted, state that explicitly.
• If a usage limit is involved, display the actual limit and reset state rather than a generic connection error.

Additional information

• Desktop OS: Darwin 27.0.0 arm64
• Browser: Google Chrome 152.0.7977.77
• Date observed: 2026-09-04 KST
• An APAC service incident affecting ChatGPT, Work, file uploads, and Codex Cloud was active during part of the observation window. The incident may explain the underlying disconnection, so this report does not claim an independent backend root cause. The reported product problem is that the fallback promised a full response, then timed out without exposing the turn's acceptance or recovery state.
• A simultaneous Plus/Pro comparison was observed, but the sessions were not sufficiently isolated and no repeated alternating A/B dataset was collected. That comparison is therefore intentionally excluded from the title and claim.
• Raw HAR files, authentication data, conversation URLs, and account identifiers are not attached publicly.

No files, tests, or code entry points are named in the report. Start by locating the Web connection-loss fallback, message-send timeout, and turn-recovery flows; done means the UI distinguishes submission, streaming, and retrieval states and clearly separates reconnecting from resending.