fix(compression): keep tool_result blocks first when aging inserts an annotation

[ntdat812]

Closes #12890

Root cause

When the compression pipeline ages (or aggressively rewrites) a user message whose content is a lone tool_result block and has no text block of its own, replaceTextContent() fell into its if (!replaced) branch and prepended a fresh {type:"text"} block:

// open-sse/services/compression/messageContent.ts (before)
if (!replaced) {
  return { ...msg, content: [{ type: "text", text: newText }, ...msg.content] };
}

For a message like [{type:"tool_result", ...}] this produces ["text", "tool_result"]. The Anthropic Messages API requires tool_result blocks to come first in the message that immediately follows a tool_use, so upstream rejects the request:

[400] messages.N: `tool_use` ids were found without `tool_result` blocks immediately after:
toolu_… Each `tool_use` block must have a corresponding `tool_result` block in the next message.

Both callers hit this branch — progressiveAging.ts (fullSummary tier tagging for user messages) and aggressive.ts (replaceContent) — so once a conversation crosses the aging threshold it fails on every subsequent turn (the reporter saw ~110 occurrences in a day).

Call site	Reaches !replaced prepend when…
progressiveAging.ts → tagAged("fullSummary", …)	user message content is a lone tool_result (no text block)
aggressive.ts → replaceContent()	same shape, aggressive mode

Fix

Only the empty-of-text branch changes. When the message carries a tool_result block, the annotation is appended after the existing content; messages without a tool_result keep the previous prepend behavior (the annotation still leads, unchanged):

if (!replaced) {
  const textBlock = { type: "text", text: newText };
  const hasToolResult = msg.content.some(
    (part) => !!part && typeof part === "object" && (part as TextBlock).type === "tool_result"
  );
  return {
    ...msg,
    content: hasToolResult ? [...msg.content, textBlock] : [textBlock, ...msg.content],
  };
}

Scoping the change to messages that actually contain a tool_result keeps the existing ordering for every other shape (plain text, image-only, multi-text), so no other compression path shifts.

Tests

New regression file tests/unit/compression/tool-result-order-12890.test.ts (4 cases), next to the sibling tests/unit/compression/aggressive-fidelity.test.ts which already covers Anthropic tool_result compression:

• lone tool_result → text block appended, tool_result stays at index 0
• two tool_result blocks → both survive, no text block precedes them
• no tool_result (image-only) → prepend behavior unchanged
• end-to-end: aging a lone-tool_result user message across the fullSummary threshold keeps tool_result before any text block

Base-revert proof — with the source change stashed out and only the test present on the base commit:

# tests 4  # pass 1  # fail 3

The 3 ordering cases fail on base (the "unchanged behavior" case passes). With the fix:

# tests 4  # pass 4  # fail 0

Commands run

# base (fix reverted, test only)
$ node --import tsx/esm --test tests/unit/compression/tool-result-order-12890.test.ts
# tests 4  # pass 1  # fail 3

# with fix
$ node --import tsx/esm --test tests/unit/compression/tool-result-order-12890.test.ts
# tests 4  # pass 4  # fail 0

# siblings (no regression)
$ node --import tsx/esm --test tests/unit/compression/aggressive-fidelity.test.ts \
    tests/unit/compression-aggressive-spare-last-user.test.ts \
    tests/unit/codex-responses-passthrough-strip-3317.test.ts
# tests 16  # pass 16  # fail 0

$ npx eslint open-sse/services/compression/messageContent.ts tests/unit/compression/tool-result-order-12890.test.ts
# clean
$ npx prettier --check <same files>   # clean

Not verified

I did not reproduce the original upstream 400 against a live Anthropic endpoint — the fix and its proof are at the replaceTextContent() unit boundary plus the applyAging() integration path, matching the block ordering the issue traced. I did not run the full suite / coverage gate or test:vitest; I ran the changed test plus its immediate siblings. The base branch is currently red independent of this change — ⚠️ base-red inherited: #12732 — so compare CI failure sets against the base rather than reading a red check as this PR's fault.

[diegosouzapw]

Thanks for the clear root-cause write-up — the diagnosis and fix here are correct, but the
identical fix already shipped via #12920 (merged 2026-09-11, same messageContent.ts function,
same append-when-tool_result / prepend-otherwise behavior, just refactored into an exported
isToolResultBlock() helper). Closing this one as a duplicate rather than merging a second
implementation of the same fix — appreciate you catching and reporting #12890 independently.

Triage note: this is the review recommendation — the close itself happens only after the maintainer's per-PR sign-off (and, where a superseding PR is named, after it has landed). Nothing is being closed by this comment.

[diegosouzapw]

Obrigado — o diagnóstico estava certo, mas o fix já entrou por outro caminho. Verifiquei contra o tip atual:

$ git log --oneline origin/release/v3.8.51 --grep="12920"
e1a1290 fix(compression): keep tool_result blocks first when aging annotates a turn (#12920)

A #12920 mergeou em 11/09 com o comportamento idêntico (append quando é tool_result, prepend caso contrário), no mesmo arquivo e na mesma função — open-sse/services/compression/messageContent.ts — refatorado num helper exportado isToolResultBlock(), que confirmei presente no tip.

Fechando como subsumida. O crédito pelo diagnóstico do ordenamento é seu.