[BUG] HTTP 400: orphaned tool_result in conversation history due to dual truncation

[suxinshuo]

Pre-checks

• I have searched existing issues and this is not a duplicate.

Deployment Method

Source (setup.sh)

Steps to Reproduce

1. Create a session with an agent that has tools enabled.
2. Send enough messages so that the conversation history contains many tool-call rounds (close to context_window_size).
3. Send a new message — the LLM call fails with HTTP 400.
4. Every subsequent message in the same session also fails.

Expected vs Actual Behavior

Conversation truncation should never produce an orphaned tool_result block. If a truncation boundary falls inside a tool-call pair, the incomplete pair should be dropped.

Logs / Screenshots

No response

[Clawiee]

Thank you for the detailed bug report! This is a well-documented issue about conversation truncation causing orphaned tool_result blocks.

Initial Analysis

Based on code review of backend/app/api/websocket.py:

1. History Loading: Chat history is loaded with .limit(ctx_size) which truncates at an arbitrary message boundary
2. Tool Call Storage: Tool calls are stored as JSON in ChatMessage with role="tool_call" containing: {"name": ..., "args": ..., "status": "done", "result": ...}
3. Conversation Reconstruction: When reconstructing for the LLM, the code creates an assistant message with tool_calls array, followed by a tool message

Root Cause: When truncation hits at ctx_size boundary, it may cut in the middle of a tool-call pair:

• Scenario: Truncation keeps the tool message but not the preceding assistant message with tool_calls
• Result: Orphaned tool message without matching tool_call_id → LLM API returns HTTP 400

The "dual truncation" mentioned: The issue likely involves two levels:

1. DB-level truncation: .limit(ctx_size) in history loading
2. API-level truncation: LLM provider rejects due to malformed conversation structure

Questions for Reproducing

Could you help us investigate further?

1. What is the approximate context_window_size setting for this agent?
2. How many tool-call rounds does the session have before the failure?
3. Is it possible to share the approximate token count when the error occurs?

Suggested Fix Direction

The truncation logic should ensure atomic tool-call pairs:

• If truncation boundary falls within a tool-call sequence, drop the incomplete pair
• Or: Apply a more sophisticated truncation that respects conversation structure (user → assistant → tool → assistant → ...)

Would you be able to help us reproduce this with specific steps or sample data?

[Clawiee]

Thank you for the detailed bug report! This is a great analysis of the "dual truncation" issue.

Root Cause Analysis:

The problem occurs at two truncation points:

1. DB Layer (websocket.py): Conversation history is loaded with limit(ctx_size) — but this counts messages, not tokens. A single tool-call round can be 10+ messages (user → assistant (tool_call) → tool → assistant → tool → ...).

2. In-memory Layer: conversation[-ctx_size:] further slices the already-truncated list.

When the truncation boundary falls inside a tool-call pair:

... [user msg] [assistant (tool_call)] [tool_result] ← orphaned if truncated here

The LLM API rejects the malformed history with HTTP 400.

Proposed Fix:

When truncating conversation history, the system should atomically drop incomplete tool-call pairs. The algorithm:

1. Before truncating, scan from the truncation point backward
2. Track tool_call/tool_result pairs
3. If truncation would leave an orphan tool_result without its tool_call:
   - Drop the orphaned tool_result
   - Continue until the boundary is at a "safe" point (between complete pairs)

Relevant code locations:

• backend/app/api/websocket.py — where ctx_size is used to load history
• backend/app/services/llm/caller.py — where conversation is passed to LLM

We'll assign this to the backend team for investigation. Could you share:

1. What context_window_size is configured for your agent?
2. Approximately how many tool-call rounds trigger the issue?
3. What LLM provider/model are you using?

This will help us reproduce and validate the fix.

[yaojin3616]

Triage Result

Field	Value
Classification	Bug
Validation	confirmed_bug
Confidence	High

Duplicate Check

• Main branch: Not fixed
• Existing PRs: Duplicate PR exists -> fix: strip orphaned tool_result messages after conversation truncation #416

Evidence

• Relevant files: backend/app/api/websocket.py
• Root cause: WebSocket history reconstruction expands each stored tool_call into an assistant + tool pair, then the subsequent conversation[-ctx_size:] truncation can drop the assistant tool_use while keeping the tool result. That produces the orphaned tool_result block described in this issue and is consistent with Anthropic HTTP 400 failures.

Next Action

• Duplicate PR exists: fix: strip orphaned tool_result messages after conversation truncation #416
• Suggested path: review and merge fix: strip orphaned tool_result messages after conversation truncation #416 instead of opening another fix PR.