openclaw - 💡(How to fix) Fix [Bug]: Matrix old room events replay as fresh inbound after gateway restart/reboot [2 comments, 2 participants]

I hit a Matrix-specific replay bug after a server reboot. After OpenClaw came back up, it appears to have processed older Matrix room events as if they were fresh inbound messages, creating new session activity and sending fresh replies into those sessions.

What happened

After a host reboot, OpenClaw restarted normally, but then multiple older Matrix events from an existing room were reprocessed. This did not look like ordinary session resume/rehydration. It looked like stale Matrix backlog being treated as new inbound.

Observed behavior:

• host rebooted
• OpenClaw restarted
• older Matrix room events were ingested again
• OpenClaw created fresh channel session activity for them
• fresh assistant replies were generated from those stale events

Why this seems wrong

I would expect one of these behaviors after restart:

• restore the Matrix sync cursor and continue from the last seen position, or
• if there is catch-up logic, dedupe already-seen Matrix event_ids / timestamps so old room history is not treated as new inbound

Instead, old events appeared to be replayed into the agent as new user messages.

Suspected root cause

My best guess is one of:

1. Matrix sync cursor loss/reset on startup
   The Matrix /sync since / next_batch token may not be getting persisted/restored correctly across restart/reboot.

2. Non-durable inbound dedupe across restart
   Even if Matrix returns some backlog on reconnect, already-seen room events may not be filtered by durable event identity (event_id) before enqueue.

3. Startup catch-up/backfill path lacks stale-event suppression
   If the Matrix channel intentionally backfills after reconnect, it may need stronger replay guards.

Environment

• OpenClaw: recent 2026.4.x build
• Channel: Matrix
• Host OS: Linux
• Incident trigger: host reboot / gateway restart

Evidence / investigation notes

I investigated locally and found:

• the behavior lined up with multiple fresh channel session updates after reboot, not just one existing session resuming
• journalctl wasn’t very helpful in this environment, so the diagnosis came from OpenClaw session/transcript state rather than explicit gateway log lines
• the failure shape looks closer to replayed inbound backlog than duplicated outbound delivery

Related issues

These seem related but not identical:

• #58443 — duplicate inbound messages / duplicate processing at runtime
• #55564 — gateway replays stale queued messages after restart

This report is narrower and specifically about Matrix old room events being replayed as fresh inbound after restart/reboot.

Maintainer ask

Could someone check:

• where Matrix sync state is persisted/restored across restart
• whether the Matrix plugin has durable dedupe by event_id
• whether startup reconnect/backfill can enqueue stale room history as fresh inbound

If helpful, I can provide redacted transcript/session timing details from the affected room.