[Bug]: OpenClaw replays the same inbound LINE turn as new user messages after provider errors #30574
Description
Summary
When a LINE inbound turn hits provider-side failures such as Gemini 429 RESOURCE_EXHAUSTED or 403 CONSUMER_SUSPENDED, OpenClaw appears to replay the same inbound LINE message as a new user turn in the session JSONL instead of retrying within the active assistant turn. This corrupts session history, duplicates user turns, and amplifies token usage and tool activity.
Steps to reproduce
Use a LINE group session backed by a provider/account that can hit transient or permanent provider failures.
Send a LINE message that triggers model/tool execution.
Ensure the provider returns retryable or terminal errors such as Gemini 429 RESOURCE_EXHAUSTED or 403 CONSUMER_SUSPENDED.
Inspect the corresponding session JSONL under ~/.openclaw/agents/main/sessions/.
Observe that the same LINE message_id is appended multiple times as distinct user messages, chained after assistant(stopReason=error) entries, before one eventual successful final response.
Expected behavior
One inbound LINE event should map to exactly one user turn in the session.
If the provider returns 429 or another retryable error, the runtime should retry inside the current assistant turn and preserve session structure.
If the provider returns a non-retryable error such as suspended credentials, the runtime should stop retrying and surface a terminal assistant-side failure state without replaying the original user turn.
Actual behavior
The same inbound LINE message_id is re-inserted into the same session as a new user message after assistant failures.
This produces sequences such as:
userassistant(stopReason=toolUse)toolResult- multiple
assistant(stopReason=error) - same LINE
message_idinserted again asuser - repeated failure cycles
- eventually one successful final response
As a result, session history no longer reflects actual user input. One real user message can appear 3 to 5 times as separate user turns.
OpenClaw version
2026.2.17
Operating system
Linux arm64
Install method
npm global
Logs, screenshots, and evidence
**1. The same LINE `message_id` is appended multiple times as distinct `user` turns**
File: `/home/ubuntu/.openclaw/agents/main/sessions/dfee868c-38dc-4211-bad4-1111866bd885.jsonl`
Examples observed in the session:
- `603126288219111922` appears 3 times
- `603127175599620318` appears 3 times
- `603131209362702921` appears 3 times
- `603152729262522559` appears 5 times
- `603152835747512377` appears 3 times
These are not flat duplicates at the same point in the log. They are appended as separate `user` nodes in the conversation chain.
**2. The replayed `user` turns are chained after failed assistant turns**
File: `/home/ubuntu/.openclaw/agents/main/sessions/dfee868c-38dc-4211-bad4-1111866bd885.jsonl`
Representative sequence for `message_id=603152729262522559`:
- `2026-03-01T04:44:31.196Z` `user`
- `2026-03-01T04:44:35.131Z` `assistant(stopReason=toolUse)`
- `2026-03-01T04:44:35.537Z` `toolResult`
- `2026-03-01T04:44:35.802Z` `assistant(stopReason=error)`
- `2026-03-01T04:44:38.066Z` `assistant(stopReason=error)`
- `2026-03-01T04:44:42.335Z` `assistant(stopReason=error)`
- `2026-03-01T04:44:50.799Z` `assistant(stopReason=error)`
- `2026-03-01T04:44:51.253Z` same LINE `message_id` inserted again as `user`
- `2026-03-01T04:44:51.798Z` same LINE `message_id` inserted again as `user`
- `2026-03-01T04:45:11.016Z` same LINE `message_id` inserted again as `user`
- `2026-03-01T04:45:33.436Z` same LINE `message_id` inserted again as `user`
- `2026-03-01T04:45:37.563Z` final successful assistant response
The `parentId` chain shows these replayed `user` messages are linked after prior failed assistant nodes, not fresh independent inbound deliveries.
**3. Failed assistant nodes contain explicit provider-side errors**
File: `/home/ubuntu/.openclaw/agents/main/sessions/dfee868c-38dc-4211-bad4-1111866bd885.jsonl`
Observed provider errors inside `assistant(stopReason=error)` entries include:
- `429 RESOURCE_EXHAUSTED`
- `Too Many Requests`
- `RetryInfo.retryDelay`
- `403 Forbidden`
- `CONSUMER_SUSPENDED`
Observed retry delays include:
- `24s`
- `21s`
- `17s`
- `9s`
- `57s`
This strongly suggests the replay behavior is triggered by provider failure handling.
**4. The repetition pattern is systematic**
File: `/home/ubuntu/.openclaw/agents/main/sessions/dfee868c-38dc-4211-bad4-1111866bd885.jsonl`
Observed counts:
- `603126288219111922`: `user=3`, `stop:error=5`, `stop:stop=1`, `final=1`
- `603127175599620318`: `user=3`, `stop:error=5`, `stop:stop=1`, `final=1`
- `603131209362702921`: `user=3`, `stop:error=5`, `stop:stop=1`, `final=1`
- `603131600573562985`: `user=1`, `stop:stop=1`, `final=1`
- `603152729262522559`: `user=5`, `stop:toolUse=3`, `stop:error=13`, `stop:stop=1`, `final=1`
- `603152835747512377`: `user=3`, `stop:error=5`, `stop:stop=1`, `final=1`
This does not look like random corruption. It looks like a repeatable retry/replay policy.
**5. Historical session reset files suggest this is not new**
Directory: `/home/ubuntu/.openclaw/agents/main/sessions/`
Older `.reset.*` session files contain long chains of `assistant(stopReason=error)` entries with Gemini quota failures as well, which suggests this runtime behavior has existed before the current session.Impact and severity
This breaks session integrity for real user conversations.
One real user message can appear multiple times as separate user turns, which:
- pollutes transcript history
- increases prompt size and API cost
- risks duplicate tool side effects
- makes debugging and auditing substantially harder
- can worsen provider quota problems because each replay re-expands context