fix: compact conversation with dangling tool calls

[uinstinct]

Description

Remove dangling tool calls when compacting conversation.

resolves CON-5063
resolves CON-4969

AI Code Review

• Team members only: AI review runs automatically when PR is opened or marked ready for review
• Team members can also trigger a review by commenting @continue-review

Checklist

• [] I've read the contributing guide
• [] The relevant docs, if any, have been updated or created
• [] The relevant tests, if any, have been updated or created

Screen recording or screenshot

before.mp4

after.mp4

Tests

[ What tests were added or updated to ensure the changes work as expected? ]

---

Continue Tasks: ▶️ 2 queued — View all

---

Summary by cubic

Fix conversation compaction to handle dangling tool calls by inserting "Tool cancelled" tool messages when a tool call has no output. Assistant messages now only reference tool calls with a corresponding result or cancellation (resolves CON-5063, CON-4969).

• Bug Fixes
  • Insert "Tool cancelled" tool messages for assistant toolCalls with no matching tool message in the filtered history.
  • Build compacted messages from the cleaned history to avoid orphan “waiting for approval” tool calls.

^{Written for commit e08aa85. Summary will update on new commits.}

[continue]

Learn more

---

All Green is an AI agent that automatically:

✅ Addresses code review comments

✅ Fixes failing CI checks

✅ Resolves merge conflicts

---

Unsubscribe from All Green comments

[continue-staging]

Learn more

---

All Green is an AI agent that automatically:

✅ Addresses code review comments

✅ Fixes failing CI checks

✅ Resolves merge conflicts

---

Unsubscribe from All Green comments

[cubic-dev-ai]

No issues found across 1 file

[RomneyDa]

@uinstinct I think this kind of filtering can result in a message being eliminated from the middle of the conversation. Probably an edge case but that can cause further API errors. I think the approach you took in the CLI of inserting a "No tool output" or "Tool cancelled" message is appropriate so that conversational ordering is preserved.

[uinstinct]

@uinstinct I think this kind of filtering can result in a message being eliminated from the middle of the conversation. Probably an edge case but that can cause further API errors. I think the approach you took in the CLI of inserting a "No tool output" or "Tool cancelled" message is appropriate so that conversational ordering is preserved.

makes sense. implemented!

[cubic-dev-ai]

10 issues found across 161 files (changes from recent commits).

Note: This PR contains a large number of files. cubic only reviews up to 75 files per PR, so some files may not have been reviewed.

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="docs/guides/run-agents-locally.mdx">

<violation number="1">
P1: Reusable workflow is referenced with a floating @main ref, making downstream CI non-reproducible and increasing supply-chain risk; pin to a release tag or commit SHA instead of main.</violation>

<violation number="2">
P2: Workflow example uses pull_request with repository secrets, which are unavailable on forked PRs; guide promises PR automation for OSS but omits this limitation and related security tradeoffs.</violation>
</file>

<file name="docs/guides/cloud-agents/cloud-agents-vs-ci.mdx">

<violation number="1">
P2: Mermaid code block closing fence is indented, leaving the block unclosed and breaking page rendering.</violation>
</file>

<file name="core/tools/implementations/resolveWorkingDirectory.vitest.ts">

<violation number="1">
P2: Vitest test file under core/tools/implementations is included in the production build because tsconfig.npm.json includes all .ts files except /test, causing dev-only vitest code to be emitted into dist.</violation>

<violation number="2">
P2: Test duplicates resolveWorkingDirectory instead of exercising the production implementation, risking drift and false confidence.</violation>

<violation number="3">
P2: Restoring HOME via assignment leaks "undefined" when it was originally unset, polluting process.env for later tests.</violation>
</file>

<file name="core/config/markdown/loadMarkdownSkills.ts">

<violation number="1">
P2: Global skills are loaded twice because the combined sources are not deduplicated, leading to duplicate Skill entries.</violation>
</file>

<file name="docs/guides/cloud-agents/from-task-to-automation.mdx">

<violation number="1">
P2: Stage section content is indented by 4+ spaces, causing Markdown to render the goal and bullet lists as code blocks instead of formatted text/lists.</violation>
</file>

<file name="docs/agents/intro.mdx">

<violation number="1">
P2: Broken docs anchor: link points to `#pre-configured-agents`, but the target section slug is `#pre-configured-cloud-agents`</violation>
</file>

<file name="docs/guides/cloud-agents/automated-security-remediation-with-snyk.mdx">

<violation number="1">
P2: Card labeled “Snyk Integration Docs” links to the general operating-safely guide instead of Snyk integration documentation</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[RomneyDa]

@uinstinct I noticed we're checking the tool call states but not the tool messages. I wonder if, IF there were already a corresponding tool message but not tool call output in the state (for some reason), this approach would cause duplicate tool messages. Could you also add checks for if a tool message is already present with the matching tool call id?

This thought comes from seeing this message recently:
{"type":"error","error":{"type":"invalid_request_error","message":"messages.8.content.4: each tool_use must have a single result. Found multiple tool_result blocks with id: toolu_01WRZpMS3e1ifYDENKX7zSU4"},"request_id":"req_011CXATvFqsCTCo9Cp38gGSW"}

We have some bug somewhere causing duplicate tool messages in CLI and I'm wondering if it could be caused by the corresponding recent fix which injects Tool cancelled without checking for tool messages

[RomneyDa]

Edit, that appears to be a CLI issue and this is for vscode/jetbrains. I did an attempt at the CLI fix here
#9596

But I think the concern is valid, let's check if tool message is there, not just tool output

[uinstinct]

@uinstinct I noticed we're checking the tool call states but not the tool messages. I wonder if, IF there were already a corresponding tool message but not tool call output in the state (for some reason), this approach would cause duplicate tool messages. Could you also add checks for if a tool message is already present with the matching tool call id?

Fair point. Implemented that changes!

(I had thought of using toolCallStates because it was a smaller array than conversation history)

[RomneyDa]

Fixes dangling tool calls during compaction