Bug: Message arrives successfully but client reports send timeout and offers duplicate-risk Retry

ChatGPT Bugs
1

Environment

  • Surface: ChatGPT Web / Windows 10
  • Browser: Microsoft Edge / Chromium-based browser
  • Exact browser version at the time: not recorded
  • Affected feature: Message sending / acknowledgement / retry state
  • Model: not relevant to the observed client-state issue

Bug

A submitted message was visibly present in the conversation and had apparently reached ChatGPT successfully.

At the same time, the sending client displayed:

“Zeitüberschreitung beim Senden der Nachricht. Bitte versuche es erneut.”
(“Message send timed out. Please try again.”)

The UI also offered a Retry action.

The message ultimately appeared ONCE.

I deliberately did not press Retry because the message was already visible in the chat and retrying could have caused a duplicate submission.

This creates an acknowledgement mismatch:

Server/message state appears successful,
while the client presents the operation as failed.

Expected behavior

The client should clearly distinguish between:

  • not sent
  • sent but awaiting acknowledgement
  • server-confirmed
  • processing
  • failed

If delivery is uncertain, the UI should show a pending/confirmation state rather than a hard send failure.

Retry should only be offered in a way that cannot create duplicate submissions.

Reproduction

Observed sequence:

  1. Work in an existing ChatGPT Web conversation.
  2. Submit a normal message.
  3. Message becomes visible in the conversation.
  4. Client simultaneously reports a send timeout.
  5. UI offers “Retry”.
  6. Message remains present once in the conversation.

The issue is especially problematic because the user cannot know whether pressing Retry is safe.

Diagnostics

Exact error:

“Zeitüberschreitung beim Senden der Nachricht. Bitte versuche es erneut.”

Approximate occurrence:

11 Sep 2026, morning / late morning
CEST (UTC+2)

The occurrence coincided with an OpenAI service interruption affecting ChatGPT users in Europe.

Frequency:

Intermittent / recurring. This report documents one clearly observed acknowledgement-mismatch case.

Suggested engineering checks:

  • unique message ID per submission
  • idempotent server-side retry / deduplication
  • explicit “Sent – confirmation pending” state
  • reconcile client state with authoritative server state before offering Retry

Acceptance criteria:

  1. A successfully received message must never be presented as an unequivocal send failure.
  2. Retry must never create a duplicate message.
  3. Delayed acknowledgement must be represented as pending/uncertain, not failed.
  4. Reload/reconnect should automatically reconcile the message with server state.
1 Like