message ordering conflict
Comprehensive Summary: Clawdbot Role Ordering Conflict Issue
Current State (as of 4:34 PM PST)
Gateway Status
- Process: clawdbot-gateway running (PID 39197)
- Listening on: ws://127.0.0.1:18789
- Telegram Provider: Started successfully
- Version: clawdbot@2026.1.15 (reinstalled at 4:33 PM)
Error Pattern (Persistent)
Message ordering conflict. I've reset the conversation - please try again.
Log Evidence
Gateway logs show:
Skipping prompt because last message is a user message (would create consecutive user turns).
Role ordering conflict (Incorrect role information: consecutive user messages would violate role ordering).
Restarting session agent:main:main -> [new-session-id]
Root Cause Analysis
The Core Problem
Session files (.jsonl) contain consecutive user messages, violating the LLM API's strict role ordering requirement: user β assistant β user β assistant (never user β user).
Why This Persists Across All Fixes
1. Session Files Were Deleted But Corruption Reappears
- Deleted bee64263-4177-419d-a30f-0c96dbd3bcba.jsonl
- Deleted d57d0dfb-6d1d-4024-b646-cd40b62c4119.jsonl
- Deleted c3b765bf-fefc-4606-834a-a685d67f0e48-topic-1.jsonl
- Gateway still processes these "ghost" session IDs
2. Session.json Registry Points to Non-existent Files
- agent:main:main pointed to 18c5d125-6df2-4a05-9fc5-c3d185f00296.jsonl (doesn't exist)
- This creates orphaned references that gateway tries to use, then fails
3. Gateway Caches Session State in Memory
- Even after deleting files and editing sessions.json, the running gateway process has corrupted session state cached
- The gateway reuses these corrupted sessions across restarts
- Restarting gateway doesn't clear in-memory state
Current State (as of 4:34 PM PST)
Gateway Status
- Process: clawdbot-gateway running (PID 39197)
- Listening on: ws://127.0.0.1:18789
- Telegram Provider: Started successfully
- Version: clawdbot@2026.1.15 (reinstalled at 4:33 PM)
Error Pattern (Persistent)
Log Evidence
Gateway logs show:
Skipping prompt because last message is a user message (would create consecutive user turns).
Role ordering conflict (Incorrect role information: consecutive user messages would violate role ordering).
Restarting session agent:main:main -> [new-session-id]
Root Cause Analysis
The Core Problem
Session files (.jsonl) contain consecutive user messages, violating the LLM API's strict role ordering requirement: user β assistant β user β assistant (never user β user).
Why This Persists Across All Fixes
1. Session Files Were Deleted But Corruption Reappears
- Deleted bee64263-4177-419d-a30f-0c96dbd3bcba.jsonl
- Deleted d57d0dfb-6d1d-4024-b646-cd40b62c4119.jsonl
- Deleted c3b765bf-fefc-4606-834a-a685d67f0e48-topic-1.jsonl
- Gateway still processes these "ghost" session IDs
2. Session.json Registry Points to Non-existent Files
- agent:main:main pointed to 18c5d125-6df2-4a05-9fc5-c3d185f00296.jsonl (doesn't exist)
- This creates orphaned references that gateway tries to use, then fails
3. Gateway Caches Session State in Memory
- Even after deleting files and editing sessions.json, the running gateway process has corrupted session state cached
- The gateway reuses these corrupted sessions across restarts
- Restarting gateway doesn't clear in-memory state
