After ChatGPT “Error in Message Stream”: Official Requests HAR and Packet Capture Before Submission

On September 23, I wrote an article titled “ChatGPT Frequently Shows “Error in Message Stream”: A Record from Network Troubleshooting to Pausing Long Tasks“, documenting how ChatGPT began frequently interrupting during long tasks, web searches, and Desktop Commander tool calls starting on September 22, along with the network troubleshooting and task recovery attempts I made at the time.

Previous article:

ChatGPT 频繁出现「消息流中的错误」：一次从网络排查到暂停长任务的记录

At that time, I had already accumulated some screenshots and local diagnostic records, and had provided OpenAI Support with materials such as the failure time, session information, and runtime environment. However, I had not yet submitted a HAR network recording that exactly covers the failure process as officially requested later. This post continues the latest progress from the previous one, rather than starting the troubleshooting from scratch.

Only After Receiving the Official Reply Did I Decide to Enable Network Capture in Advance

After further communication, OpenAI Support replied to the original ticket, explicitly requesting a HAR captured at the time of the failure. The support agent confirmed that the previously provided screenshots and environment information had been received, noted that they did not need to be resent, and advised against repeatedly running additional tests just to reproduce the issue.

Therefore, following the steps provided in the email, I opened the “Network” panel in Firefox Developer Tools today, enabled “Persist Logs”, and kept the recording running while preparing to use ChatGPT normally. The previously accumulated diagnostic materials remain useful; what I needed to supplement this time was the HAR file with the failure timeline specifically requested by the official team.

By this evening, I noticed two occurrences of “Error in message stream”. When the first one occurred, I had not yet completed the required network capture; when the second one happened, network recording was already running.

Interruption Recurred While Translating the Third Batch of Gujarati

The second failure occurred while working on the Gujarati (gu-IN) translation for the A Tour of Go multilingual translation project. I was processing the formal translation input for the third batch of 19 Examples, using GPT-5.6 Sol High.

The ChatGPT page displayed the red “Error in message stream” again. This time, instead of rushing to refresh the page or repeatedly clicking “Retry”, I first preserved the live state in the Developer Tools.

As seen in this console screenshot, multiple XHR requests to the ChatGPT backend API returned HTTP 429, along with CSP errors and Source Map 404 messages. 429 usually indicates that a request is rate-limited, but we cannot conclude solely from the console screenshot that it caused the message stream interruption; the actual request timeline and response details still need to be analyzed by the support team using the HAR.

Saving the HAR and Console Logs as Officially Requested

The reason I captured the network traffic in advance this time was because Support made a clear request in the email: keep network recording on during normal use, export a HAR of an affected session when the next failure occurs, and reply to the original ticket.

I then selected “Save All As HAR” in the Firefox Network panel to save the network activity at the time of the failure. I did not refresh the page or clear the network logs before saving.

To allow the support agent to directly search the error messages, I also switched to the “Console” and exported a text log via “Save All Messages to File”, rather than just keeping screenshots.

The two files obtained this time are:

• chatgpt.com_Archive [26-09-26 18-36-51].har, approximately 31.9 MB;
• console-export-2026-9-26_18-40-16.log, containing console errors, warnings, and related request records.

The timestamps here are all in Beijing Time (UTC+8): the HAR file was saved at approximately 18:36, and the console log was saved at approximately 18:40.

HAR Exceeds Gmail Limit, Switched to Google Drive Sharing

While preparing to reply to the email, I noticed that the HAR was larger than Gmail’s 25 MB attachment limit. Gmail then uploaded the large file to Google Drive and inserted a file link in the email.

I did not set the file to “Anyone with the link can access”; instead, upon sending, I granted view permissions only to the Support recipient of the original ticket. The console log was also attached to the reply along with the HAR.

Finally, I replied to the original ticket at approximately 18:47 today. The email explained the failure scenario, capture time, and the multiple HTTP 429 occurrences in the console, while also explicitly stating that it is not yet possible to determine whether a direct causal relationship exists between these responses and the message stream interruption.

Fewer Errors Today, But It Is Too Early to Say It Is Fixed

Compared to the previous few days of frequent interruptions, I only observed two errors by this evening, so the subjective experience is indeed improved. However, this is just today’s usage record; it does not mean the failure has been resolved, nor can it be inferred that OpenAI’s backend has already implemented a fix.

The real progress made this time is: After the official team explicitly requested a HAR, I prepared the capture in advance and successfully submitted the HAR and console log of an affected session to the original ticket. The previous screenshots, network troubleshooting, and recovery experience were not in vain, and I have now finally provided the key materials needed by the support team.

Now I just need to wait for OpenAI Support’s analysis and feedback. There is no need to deliberately run another long task that might interrupt just to increase the sample size. I will update this incident tracking record once I receive a further reply.