Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug] Streaming gets stuck: message_start error even with single messages (Telegram, v2026.3.24) [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#55399•Fetched 2026-04-08 01:40:01
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
imydalimydal
Participants
imydalimydal
Timeline (top)
cross-referenced ×1

Error Message

This happens even with a single message — not just with rapid successive messages as reported in #7721 and #47084. The gateway appears to remain in a "streaming" state after a response completes, causing the next message (even minutes later) to trigger the error. 4. Intermittently, the error appears — the gateway seems stuck thinking a previous stream is still active

  • New messages trigger the message_start before message_stop error
  • The error is displayed to the user in the Telegram chat
  • Possibly related to tool calls during streaming (the error often occurs after responses that involved multiple tool calls)
  • #7721 — Original streaming error report

PR fix notes

PR #55999: fix(telegram): sanitize invalid stream-order errors

Description (problem / solution / changelog)

Summary

  • treat invalid provider stream-order failures as a safe retryable user-facing error
  • cover both assistant-error formatting and explicit user-facing sanitization paths
  • add unreleased changelog credit for the original reporter and maintainer follow-up

Validation

  • pnpm test -- src/agents/pi-embedded-helpers.formatassistanterrortext.test.ts src/agents/pi-embedded-helpers.sanitizeuserfacingtext.test.ts
  • pnpm build

Fixes #55408 Related #55399

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/pi-embedded-helpers.formatassistanterrortext.test.ts (modified, +9/-0)
  • src/agents/pi-embedded-helpers.sanitizeuserfacingtext.test.ts (modified, +11/-0)
  • src/agents/pi-embedded-helpers/errors.ts (modified, +20/-0)

Code Example

Unexpected event order, got message_start before receiving "message_stop"
RAW_BUFFERClick to expand / collapse

Bug Description

The gateway intermittently gets stuck in a streaming state and throws:

Unexpected event order, got message_start before receiving "message_stop"

This happens even with a single message — not just with rapid successive messages as reported in #7721 and #47084. The gateway appears to remain in a "streaming" state after a response completes, causing the next message (even minutes later) to trigger the error.

Steps to Reproduce

  1. Send a message via Telegram (direct chat, single message)
  2. Wait for the full response to complete
  3. Send another message
  4. Intermittently, the error appears — the gateway seems stuck thinking a previous stream is still active

Expected Behavior

Each message should be processed independently. After a response completes (message_stop), the gateway should be ready for the next message_start.

Actual Behavior

  • The gateway gets stuck in a streaming state
  • New messages trigger the message_start before message_stop error
  • The error is displayed to the user in the Telegram chat
  • Requires /reset or openclaw gateway restart to recover

Environment

  • OpenClaw version: 2026.3.24 (cff6dc9)
  • Platform: Linux (Ubuntu, x64)
  • Channel: Telegram (direct chat)
  • Model provider: MyClaw (Claude Opus 4.6 via api.myclaw.ai)
  • Node: v22.22.1

Additional Context

  • This is NOT limited to rapid successive messages — it happens with normal single messages after the previous response is fully complete
  • Possibly related to tool calls during streaming (the error often occurs after responses that involved multiple tool calls)
  • The bug persists from at least v2026.2.1 (#7721) through v2026.3.24
  • /reset temporarily fixes the issue, but it recurs

Related Issues

  • #7721 — Original streaming error report
  • #47084 — Telegram race condition variant
  • #9267 — Skill-triggered variant

extent analysis

Fix Plan

To resolve the intermittent streaming state issue, we need to ensure that the gateway properly resets after each message response completes. Here are the steps:

  • Modify the response completion handler:
    • Check if the current message has been fully processed (message_stop received).
    • If so, reset the streaming state to allow for new messages.
  • Implement a timeout for streaming state:
    • Set a reasonable timeout (e.g.,

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#docker error#permission error#memory optimization#batch processing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING