[Bug] OpenClaw plugin assemble() produces consecutive user turns after archive commit — causes empty responses from Gemini/Anthropic

[benediktkraus]

[Bug] OpenClaw plugin assemble() produces consecutive user turns after archive commit — causes empty responses from Gemini/Anthropic

Summary

After an OpenViking session archive commit, buildAssembledContext() in the OpenClaw context-engine plugin produces multiple consecutive user-role messages. This violates the strict alternating turn ordering required by Gemini and Anthropic APIs, causing stopReason=stop payloads=0 (empty model response) on every subsequent turn until the session is manually deleted.

Reproduction

1. Send ~30-40 messages to an OpenClaw agent (Gemini Pro) with the OpenViking context-engine plugin active
2. Wait for commitTokenThreshold to trigger automatic commit(wait=false) with archived=true
3. Send another message after archive completes
4. Agent returns: ⚠️ Agent couldn't generate a response. Please try again.
5. Every subsequent message fails identically — the session is permanently broken

Root Cause

buildArchiveMemory() (context-engine.ts) creates archive context as role: "user" messages:

messages.push({ role: "user", content: `[Session History Summary]\n${archiveOverview}` });
messages.push({ role: "user", content: `[Archive Index]\n${lines.join("\n")}` });

buildAssembledContext() concatenates archive + session messages:

const assembled = [...archive.messages, ...session.messages];

After archive, if session.messages is empty or starts with a user message, the assembled array becomes:

user: [Session History Summary]...
user: [Archive Index]...
user: <new message>

Three consecutive user turns. sanitizeToolUseResultPairing() repairs tool-use/result pairing but does NOT merge consecutive user turns. mergeConsecutiveAssistants() exists for assistant turns but has no user counterpart.

The OpenClaw SDK provides validateGeminiTurns() and mergeConsecutiveUserTurns() in pi-embedded-helpers/turns.js, but the OV plugin does not call them, and the OC runtime only calls validateGeminiTurns in the replay path.

Gateway Log Pattern

openviking: committed session=XXX, status=accepted, archived=true
openviking: assemble entering session content for XXX: [{"role":"user","content":"[Session History Summary]..."},{"role":"user","content":"..."}]
empty response detected: runId=XXX provider=google/gemini-3.1-pro-preview — retrying 1/1
empty response retries exhausted: runId=XXX attempts=1/1
incomplete turn detected: runId=XXX stopReason=stop payloads=0 — surfacing error to user

Suggested Fix

Add mergeConsecutiveUsers() analogous to mergeConsecutiveAssistants(), call after sanitizeToolUseResultPairing().

Environment

• OpenClaw: 2026.4.24, OpenViking: v0.3.12, Plugin: @openclaw/openviking@2026.4.34
• Provider: Google Gemini 3.1 Pro

Workaround

Delete the session file and restart gateway. Recurs after next archive commit.

[MaiHHConnect]

💬 我也在做记忆系统相关的工作：CausaMem，可以来看看，说不定有能借鉴的地方 🙂

[benediktkraus]

Update: Additional consecutive-user-turn sources identified (2026-04-27)

The original report correctly identifies archive commit as one trigger. After deeper investigation, we found two additional sources of consecutive user turns that compound the problem:

Source 2: OpenClaw yield events

OC injects yield-related messages as role: "user":

• [sessions_yield interrupt] — injected when a turn yields
• Turn yielded. [Context: The previous turn ended intentionally via sessions_yield...] — injected on resume

These appear between the archive summary and the next real user message, creating sequences like:

user: [Session History Summary]...    ← OV archive
user: [sessions_yield interrupt]      ← OC yield
user: Turn yielded. [Context: ...]    ← OC yield
user: <actual user message>           ← Telegram

Four consecutive user turns. This happens even WITHOUT an archive commit — any session with yield events can trigger it.

Source 3: Audio/Telegram metadata injection

[Audio] User text: [Telegram Benedikt Kraus...] is injected as role: "user" and can stack with yield events.

Impact

12 occurrences in a single day (2026-04-26), across 2 different sessions:

• Session 2e033dab: 9 failures (10:54–19:40)
• Session c9a38e09: 3 failures (20:34–21:05)

The session is not "permanently broken" as originally reported — it fails on turns where the role sequence happens to produce consecutive users, but can succeed on turns where tool results create a valid alternation. However, the failure rate is high enough (>50% of turns) to make the agent effectively unusable.

Confirmed: mergeConsecutiveAssistants() exists but no user counterpart

context-engine.ts L529 has mergeConsecutiveAssistants() which is called at L549. No equivalent mergeConsecutiveUsers() exists. The sanitizeToolUseResultPairing() at L799 repairs tool-use pairing but does not address consecutive user turns.

OpenClaw SDK provides mergeConsecutiveUserTurns() and validateGeminiTurns() in pi-embedded-helpers/turns.d.ts, but these are not importable by the extension at runtime.

Proposed fix (local patch)

Insert after L799 (sanitizeToolUseResultPairing):

function mergeConsecutiveUsers(messages: AgentMessage[]): AgentMessage[] {
  const result: AgentMessage[] = [];
  for (const msg of messages) {
    const prev = result[result.length - 1];
    if (prev && prev.role === "user" && msg.role === "user") {
      const prevText = typeof prev.content === "string" ? prev.content : JSON.stringify(prev.content);
      const currText = typeof msg.content === "string" ? msg.content : JSON.stringify(msg.content);
      result[result.length - 1] = { ...prev, content: prevText + "\n\n" + currText };
    } else {
      result.push(msg);
    }
  }
  return result;
}

Then replace sanitized with mergeConsecutiveUsers(sanitized) in the assemble return path.

We will apply this local patch and report results.