Bug: "reply session initialization conflicted" — session stuck in "running" status with GLM-5.2 cloud model

Summary

When using ollama/glm-5.2:cloud as the model provider, the main session (agent:main:main) gets stuck in "status": "running" between turns. Every subsequent webchat message then fails with:

Error: reply session initialization conflicted for agent:main:main

This happens randomly — not just after restarts. The error occurs because the replyResolver tries to initialize a new session turn but conflicts with the stale "running" state from the previous turn.

Environment

• OpenClaw version: 2026.6.11 (e085fa1)
• OS: Ubuntu 24.04.4 LTS
• Model: ollama/glm-5.2:cloud (via Ollama Cloud)
• Channel: webchat (Control UI)
• Gateway bind: loopback

Evidence

Session state shows stuck "running" status

{
  "sessionId": "1596b063-ebfd-4656-9fae-443d6f45724e",
  "status": "running",
  "startedAt": 1782934320351,
  "abortedLastRun": false,
  "model": "glm-5.2:cloud"
}

The session stays in "running" even after the model has finished responding and the reply has been delivered to the user.

Error logs (24 occurrences in one session)

2026-07-01T13:06:46.571-06:00 [diagnostic] message dispatch completed: channel=webchat sessionId=unknown sessionKey=agent:main:main source=replyResolver outcome=error duration=9ms error="Error: reply session initialization conflicted for agent:main:main"
2026-07-01T13:06:57.689-06:00 [diagnostic] message dispatch completed: channel=webchat sessionId=unknown sessionKey=agent:main:main source=replyResolver outcome=error duration=23ms error="Error: reply session initialization conflicted for agent:main:main"
... (continues for every message until session state is manually cleared)

Note: sessionId=unknown on every error — the replyResolver can't resolve the session ID because of the conflict.

Pattern

The errors come in clusters:

1. After gateway restarts (expected — session reinitialization)
2. Randomly during normal operation — a turn completes, reply is delivered, but session status stays "running", and all subsequent messages fail until the state somehow clears

Source code reference

In dist/get-reply-D-_K5pna.js, the error is thrown after a single stale-snapshot retry:

if (!committed.ok) {
    if (!staleSnapshotRetried) return await initSessionStateAttempt(params, true);
    throw new Error(`reply session initialization conflicted for ${sessionKey}`);
}

Hypothesis

GLM-5.2 (via Ollama Cloud) may not be sending a clean turn-completion signal that OpenClaw expects, causing the session to remain locked in "running" state. The replyResolver then fails on the next message because it can't commit a new session entry while the previous one is still marked as running.

This did not occur with previous models (kimi-k2.5:cloud, gemma4:31b:cloud) based on available logs (logs only go back ~2 weeks, but zero errors before July 1, 2026 — the day the model was switched to GLM-5.2).

Impact

• Messages from webchat silently fail (user sees error spam)
• The agent still responds when the session state happens to clear, but the behavior is unpredictable
• Requires gateway restart to reliably clear the stuck state

Suggested fixes

1. More aggressive session state recovery — if a session is stuck in "running" for longer than a timeout (e.g. 5 minutes with no active model call), automatically mark it as not-running
2. Better turn-completion detection for Ollama Cloud models that may have non-standard completion signaling
3. Retry with backoff for replyResolver conflicts (already exists for Telegram spooled updates per monitor-polling.runtime, could be extended to webchat)

Workaround

Restarting the gateway temporarily clears the stuck state, but the issue recurs within a few messages.