Long-running Work/Project turns fail silently — resume returns 404/410 while backend keeps reporting IS_STREAMING (Case #14822677, 2+ weeks unresolved)

ChatGPT Bugs
1

Environment

  • Surface: Web
  • Browser or app version: Windows 11, tested in both Brave (private mode, Shields off) and Microsoft Edge (private mode, default/no extensions) — same failure in both
  • Affected feature and model: ChatGPT Projects / Work mode, GPT-5.6 Sol, High reasoning

Bug
What happened, and what did you expect?
A long-running research turn (often close to completion) breaks mid-stream with ERR_HTTP2_PROTOCOL_ERROR (HTTP 200). ChatGPT automatically attempts /conversation/resume, which returns either 404 “Resume stream unavailable” or 410 Gone. Despite the resume failing, /stream_status keeps returning {"status":"IS_STREAMING"} for several minutes afterward, before the UI finally times out with “Message delivery timed out. Please try again.” Expected: the turn either completes normally or fails cleanly — not a resume rejection followed by a stuck streaming status for minutes.

Reproduction
Steps or a minimal example prompt:

  1. Start a long, tool-heavy High-reasoning research turn in a Project (10+ minutes)
  2. Let it run without interacting
  3. Failure occurs partway through — as early as 11–12 minutes in, sometimes not until 20+ minutes
  4. Reproduced in the original Project, in a brand-new Project created specifically as a control, and in a fresh private browser session — rules out one corrupted conversation or a browser/extension cause
  5. Successful control runs completed normally at 17m29s and 21m23s, ruling out a fixed timeout

Diagnostics
Exact error or screenshot:
ERR_HTTP2_PROTOCOL_ERROR → /conversation/resume returns 404/410 → /stream_status returns IS_STREAMING repeatedly → “Message delivery timed out.” A related but distinct failure also captured: immediate HTTP 503 with unexpected_content_type, zero streamed bytes.

When it happened (with timezone) and how often:
Recurring over two-plus weeks (mid-September 2026 onward), AEST (UTC+10). Documented in 14 separate HAR files across 10 numbered controlled tests plus 4 real-world captures — OpenAI Support Case #14822677. Most recent Support reply, in writing: “I do not have a documented engineering review result or linked engineering ticket in the case that would allow me to confirm that an engineer has already reviewed the diagnostic evidence you submitted.”

2

Update, Oct 2: After 22 days of consistent failures (earliest documented: Sep 11), my own testing today suggests the issue may no longer be reproducing — basic prompts and a stress test in the same previously-affected Project both completed normally.

Worth being clear about what that does and doesn’t mean: this is not an OpenAI confirmation of anything. Across three separate channels — this support case (#14822677), the Help Center live chat, and this very forum post — I have received precisely zero acknowledgment, let alone confirmation of a fix, mitigation, or root cause. I’m reporting what I’m observing on my end, not what OpenAI has told me, because they haven’t told me anything.

If anyone else here (@Daareek, @NazTeclas, or others on the same Sol/High-reasoning signature) is seeing similar recovery, worth noting here — and if anyone has gotten an actual response from staff on this, I’d genuinely like to know what channel worked.

3

Update — OpenAI Support has now confirmed there was no Engineering investigation

I have an important update on Case #14822677, concerning the long-response/streaming failure I experienced.

After more than three weeks of repeated failures — including stalled responses, stream interruptions, /conversation/resume failures, delivery/connection timeouts and blank responses — I eventually found that the problem stopped reproducing without any intervention that I am aware of.

I then contacted Support again because I wanted to establish what had changed and whether it was actually safe for me to resubscribe.

I have now received a response from OpenAI Support after they reviewed the case history.

The significant part is that OpenAI has explicitly confirmed:

“Case #14822677 was not escalated to an Engineering team, so there is no Engineering review, identified fix, or case-specific mitigation documented in the ticket that I can attribute to the improvement you’re now seeing.”

They also acknowledged that the case contained evidence of:

  • interrupted or stalled responses

  • conversation resume failures

  • connection and delivery timeouts

  • blank-screen behaviour

  • HAR files

  • screenshots

  • technical reports

  • conversation references

  • controlled testing

They also confirmed that my latest testing shows the problem is currently no longer reproducing, including basic prompts and a stress test, but that the case record does not establish what changed or why the previous behaviour stopped occurring.

So, at this point, there is no confirmed fix, no identified root cause, and no documented mitigation.

The particularly frustrating part is that this leaves me in exactly the position I was trying to resolve: Can I safely resubscribe, or could the problem simply return?

I have asked Support what practical option they can offer now — for example, whether I can test GPT-5.6 Terra, which was the model/configuration involved when the problem originally occurred, whether another model/configuration can be provided for testing, or whether the case can finally be escalated to Engineering.

I am not asking Support to invent a root cause. I understand that they may not know what changed.

But after a month of providing evidence and performing the troubleshooting requested, I think it is reasonable to ask for some actionable way to establish whether the problem is actually resolved before paying for the service again.

One other important point

I also received a separate Support response concerning the recording I supplied.

That response focused on one conversation in the recording reaching its normal conversation-length limit.

That was not the problem demonstrated by the recording.

The recording showed several conversations using a simple TEST prompt. The point was to demonstrate the current state of the environment where the previous long-response failure had occurred. One conversation did take longer because it had actually reached its conversation limit, and the conversation itself explicitly explained that. I already understand that limitation.

The issue I originally reported was the different behaviour where a prompt could run for around 20+ minutes, stop producing the response, and exhibit the stream/resume failures documented in the HAR evidence.

The later Support response is much clearer because it explicitly acknowledges those original streaming/resume/delivery problems in the case history.

Current status

The problem currently appears to be working again, but OpenAI cannot tell me why.

There is currently:

  • :cross_mark: No confirmed Engineering fix

  • :cross_mark: No confirmed root cause

  • :cross_mark: No documented mitigation

  • :cross_mark: No explanation for why the problem stopped

  • :red_question_mark: No confirmation that it won’t return

I’m posting this update because several people have been following this issue and asking whether OpenAI had eventually identified or fixed it.

The answer, according to Support, is currently no.