Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Infinite message delivery loop tied to session persistence in v2026.4.2 [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#60110•Fetched 2026-04-08 02:36:08
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
getkevinwanggetkevinwang
Participants
getkevinwanggetkevinwang
Timeline (top)
labeled ×2

Root Cause

Even after restarting the Gateway service, the loop persisted because the pending message was saved in the persistent session files and reloaded upon restart without being marked as 'delivered'.

Fix Action

Workaround

The only way to stop the loop was to:

  1. Shut down the Gateway.
  2. Force-delete all files in ~/.openclaw/agents/main/sessions/.
  3. Restart Gateway to start a fresh sequence.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Version

OpenClaw 2026.4.2 (d74a122)

Describe the Bug

After upgrading to v4.2, the Gateway entered an infinite message delivery loop. A specific message (e.g., status updates from a sub-agent task) would be delivered repeatedly.

Even after restarting the Gateway service, the loop persisted because the pending message was saved in the persistent session files and reloaded upon restart without being marked as 'delivered'.

Root Cause (Observed)

The pending-replies logic in session persistence appears to get stuck. The Gateway keeps reading the same "to-be-sent" instruction from the session JSON/JSONL record and never successfully clears or updates the status flags within the physical session files.

Steps to Reproduce

  1. Trigger a multi-step task involving a sub-agent (e.g., researcher).
  2. Encounter a timeout or concurrency lock.
  3. Observe the Gateway repeatedly sending the same message.
  4. Restart Gateway -> Observation: The repetition resumes immediately from the old session state.

Workaround

The only way to stop the loop was to:

  1. Shut down the Gateway.
  2. Force-delete all files in ~/.openclaw/agents/main/sessions/.
  3. Restart Gateway to start a fresh sequence.

Suggested Fix

Ensure that once the Gateway picks up a pending reply from the persistent store, it is atomically marked or immediately suppressed if delivery is already in progress, preventing re-reads from triggering loops.

Steps to reproduce

n/a

Expected behavior

n/a

Actual behavior

n/a

OpenClaw version

2026.4.2

Operating system

macOS 26.4

Install method

No response

Model

gemini-3-flash

Provider / routing chain

gemini

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The Gateway's infinite message delivery loop can be fixed by ensuring that pending replies are atomically marked or suppressed once picked up from the persistent store to prevent re-reads.

Guidance

  • Review the pending-replies logic in session persistence to identify why it gets stuck and fails to clear or update status flags in the session files.
  • Implement a mechanism to atomically mark or suppress pending replies once they are picked up from the persistent store to prevent re-reads and loops.
  • Consider adding a check to detect and prevent concurrent deliveries of the same message to avoid loops.
  • Verify that the fix works by reproducing the issue and checking that the Gateway no longer enters an infinite loop after the changes.

Example

No code snippet is provided as the issue does not contain sufficient code details.

Notes

The provided workaround suggests that deleting the session files and restarting the Gateway can temporarily resolve the issue, but a permanent fix is needed to prevent the loop from occurring in the first place.

Recommendation

Apply workaround: The suggested fix should be implemented to ensure that pending replies are properly marked or suppressed to prevent infinite loops. This will require changes to the pending-replies logic in session persistence.

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…

FAQ

Expected behavior

n/a

#api#ssr#installation#tensor shape#request timeout

Still need to ship something?

×6

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

Back to top recommendations

TRENDING