fix(agents): preserve tool call/result pairing in history limiting by steve-rodri · Pull Request #2557 · openclaw/openclaw

steve-rodri · 2026-01-27T03:45:09Z

Problem

The limitHistoryTurns() function in src/agents/pi-embedded-runner/history.ts was slicing conversation history without considering tool call/result pairing. When limiting history to the last N user turns, it could cut off tool results from their corresponding assistant tool calls, causing Anthropic API validation errors:

LLM request rejected: messages.266.content.1: unexpected tool_use_id found in tool_result blocks: toolu_01K7ZFJdfEDqTsKuikvRRfmi. Each tool_result block must have a corresponding tool_use block in the previous message.

Solution

Modified limitHistoryTurns() to be tool-call-aware:

Added hasToolCalls() helper to detect assistants with tool calls
Added countFollowingToolResults() helper to count tool results
Before slicing at a boundary, check if there's a toolResult message immediately before the slice point
If found, walk back through consecutive tool results to find the corresponding assistant
Adjust the slice point to include the complete assistant + tool results sequence

Impact

This ensures tool call/result pairs stay together when limiting history via dmHistoryLimit config, preventing the Anthropic API validation error.

Testing

Existing limithistoryturns tests pass
Fix verified to resolve the reported error

Greptile Overview

Greptile Summary

This PR updates limitHistoryTurns() (src/agents/pi-embedded-runner/history.ts) to avoid slicing conversation history in a way that separates an assistant tool-call turn from its subsequent toolResult messages, which can cause strict provider validation errors.

The new logic detects when the slice boundary would start immediately after one or more trailing toolResult messages and moves the slice start backward to include the corresponding assistant tool-call message as well.

Confidence Score: 4/5

This PR is likely safe to merge and should reduce tool pairing validation errors, with minor edge-case coverage gaps.
The change is localized to history slicing and doesn’t affect core execution paths beyond deciding the slice start index. Main risk is behavioral mismatch in uncommon transcript shapes (e.g., toolResult blocks not immediately adjacent to the slice boundary, or tool call detection not matching all variants), plus a small amount of dead code left behind.
src/agents/pi-embedded-runner/history.ts

_{(4/5) You can add custom instructions or style guidelines for the agent here!}

Context used:

Context from dashboard - CLAUDE.md (source)
Context from dashboard - AGENTS.md (source)

Fixes issue where limitHistoryTurns() could orphan tool results by slicing conversation history between an assistant's tool calls and their results. This caused Anthropic API validation errors: 'unexpected tool_use_id found in tool_result blocks... Each tool_result block must have a corresponding tool_use block in the previous message' Changes: - Add hasToolCalls() helper to detect assistants with tool calls - Add countFollowingToolResults() helper to count tool results - Check for toolResult messages at slice boundaries - Adjust slice point to include complete assistant + toolResults sequence The fix ensures tool call/result pairs stay together when limiting history via dmHistoryLimit config. Co-Authored-By: Claude Opus 4.5 <[email protected]>

greptile-apps

_{1 file reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-03T03:58:22Z

src/agents/pi-embedded-runner/history.ts

+function countFollowingToolResults(messages: AgentMessage[], startIndex: number): number {
+  let count = 0;
+  for (let i = startIndex + 1; i < messages.length; i++) {
+    if (messages[i].role === "toolResult") {
+      count++;
+    } else {
+      break;
+    }
+  }
+  return count;
+}


countFollowingToolResults() is added but never used in this file, which looks like leftover logic from an earlier iteration. Keeping it unused adds noise and may mislead readers about intended behavior.

If it’s not needed, consider removing it; if it is needed, add the call site so the helper is justified.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/pi-embedded-runner/history.ts Line: 34:44 Comment: `countFollowingToolResults()` is added but never used in this file, which looks like leftover logic from an earlier iteration. Keeping it unused adds noise and may mislead readers about intended behavior. If it’s not needed, consider removing it; if it is needed, add the call site so the helper is justified. <sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub> How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-03T03:58:23Z

src/agents/pi-embedded-runner/history.ts

+        // Only adjust if there's actually a toolResult at the boundary
+        if (lastUserIndex > 0 && messages[lastUserIndex - 1].role === "toolResult") {
+          // Walk back through consecutive tool result messages to find the assistant
+          let j = lastUserIndex - 1;
+          while (j >= 0 && messages[j].role === "toolResult") {
+            j--;
+          }
+
+          // If we found an assistant with tool calls immediately before the tool results,
+          // we need to include it to avoid breaking the tool call/result pairing.
+          if (j >= 0 && hasToolCalls(messages[j])) {
+            sliceIndex = j;
+          }
+        }


The boundary fix only triggers when messages[lastUserIndex - 1] is a toolResult, but tool results can be separated by non-assistant “remainder” entries (see repairToolUseResultPairing() allowing non-toolResult remainder between assistant turns). In that case, slicing at lastUserIndex can still orphan those toolResults (and their tool call) even though the message immediately before the boundary isn’t a toolResult.

This matters if your transcripts can contain e.g. assistant(toolCall) → toolResult → custom/metadata → user, because the current check won’t walk back across that non-toolResult entry to preserve the whole tool span.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/pi-embedded-runner/history.ts Line: 72:85 Comment: The boundary fix only triggers when `messages[lastUserIndex - 1]` is a `toolResult`, but tool results can be separated by non-assistant “remainder” entries (see `repairToolUseResultPairing()` allowing non-toolResult `remainder` between assistant turns). In that case, slicing at `lastUserIndex` can still orphan those toolResults (and their tool call) even though the message immediately before the boundary isn’t a `toolResult`. This matters if your transcripts can contain e.g. `assistant(toolCall)` → `toolResult` → `custom/metadata` → `user`, because the current check won’t walk back across that non-toolResult entry to preserve the whole tool span. How can I resolve this? If you propose a fix, please make it concise.

openclaw-barnacle bot added the agents Agent runtime and tooling label Jan 27, 2026

koriyoshi2041 mentioned this pull request Jan 28, 2026

fix: skip incomplete tool calls in transcript repair [AI-assisted] #3194

Closed

6 tasks

This was referenced Feb 2, 2026

fix(session): strip malformed tool_use blocks to prevent session corruption #5557

Closed

fix(agents): skip extracting tool calls from errored assistant turns #1859

Closed

greptile-apps bot reviewed Feb 3, 2026

View reviewed changes

sebslight mentioned this pull request Feb 13, 2026

Agents: fix orphaned toolResult after history truncation #5738

Closed

3 tasks

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comments

fix(agents): preserve tool call/result pairing in history limiting#2557

fix(agents): preserve tool call/result pairing in history limiting#2557
steve-rodri wants to merge 1 commit intoopenclaw:mainfrom
steve-rodri:fix/tool-result-pairing-history

steve-rodri commented Jan 27, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Comments

Conversation

steve-rodri commented Jan 27, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Impact

Testing

Greptile Overview

Greptile Summary

Confidence Score: 4/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

steve-rodri commented Jan 27, 2026 •

edited by greptile-apps bot

Loading