fix(conversations): Stop rendering raw tool call JSON as message content

[obostjancic]

When an assistant response contains only tool calls without text, parseAssistantContent would fall through to gen_ai.response.objectand render the raw tool call JSON as message content. This caused:

1. Raw JSON blobs appearing in conversation messages
2. Duplicate rendering of tool calls (badges + JSON content)

Fix by detecting tool-call-only outputs in extractAssistantOutput andreturning null instead of falling through to response attributes. Also creates assistant messages for tool-call-only turns so the tool call badges still render, and skips the content area when message content is empty.

Before:

After:

Closes TET-2448

[linear-code]

TET-2448

[github-actions]

📊 Type Coverage Diff

✅ no issues found

[sharvan9515]

🟠 high · possible confidence

Null Content Guard — The guard message.content !== '' only skips rendering when content is exactly an empty string. If content can be null or undefined at runtime (the old code set content: turn.assistantContent which could be null), the condition evaluates to true and AIContentRenderer receives a null/undefined text prop, which may throw or render incorrectly. The new code sets content: turn.assistantContent ?? '' so this should be safe for newly created messages, but any cached or legacy message objects with content: null would bypass the guard.

[sharvan9515]

✅ Implements the stated intent

Intent: Fix raw tool-call JSON appearing as message content by detecting tool-call-only assistant outputs and returning null instead of falling through to response attributes, and skip rendering the content area when content is empty.

This PR fixes an issue where tool-call-only assistant outputs were rendering raw JSON as message content. The fix detects when an assistant message contains only tool calls (no text) and returns null from parseAssistantContent, then guards the content rendering in MessagesPanel to skip when content is empty. Finding [1] identifies a critical gap: the guard checks message.content !== '' but doesn't handle the case where content is null, which would still attempt to render and likely cause an error.

Findings (1): 1 high · 📍 1 commented inline on changed lines

Severity	Location	Issue
🟠 high	static/app/views/explore/conversations/components/messagesPanel.tsx:129	Null Content Guard — The guard message.content !== '' only skips rendering when content is exactly an empty string. If content can be null or undefined at runtime (the old code set content: turn.assistantContent which could be null), the condition evaluates to true and `AIContentRendere…

📋 Basis of review

Examined control flow in conversationMessages.ts and messagesPanel.tsx, checked the new conditional rendering guard, the flush logic in mergeEmptyTurns, and the hasAssistantContent/hasToolCalls branching in turnsToMessages. Also reviewed the new test cases for correctness.

🔍 Needs human verification

1. Confirm at runtime that assistant messages with only tool calls render the tool-call badges correctly without any content area, and that no visual regression occurs for normal text-only or mixed text+tool-call messages. 2. Verify that the mergeEmptyTurns flush (appending pending tool calls to the last result turn) does not cause duplicate tool-call badges when the last turn already has tool calls from a previous merge step. 3. Confirm that message.content !== '' is the right guard — if content can ever be undefined or null at runtime (e.g., from older data), the guard would pass and AIContentRenderer would receive a falsy value.

[sharvan9515]

🟡 medium · likely confidence

Deduplication Bypass — The hasAssistantContent check uses seenAssistantContent.has(turn.assistantContent) to deduplicate, but when hasToolCalls is true and assistantContent is null, the block is entered via hasToolCalls without adding anything to seenAssistantContent. If a subsequent turn has the same null/empty assistantContent with tool calls, it will also pass through. More importantly, if hasAssistantContent is false (content already seen) but hasToolCalls is true, the block is entered and an assistant message is emitted with the duplicate content set to turn.assistantContent ?? ''. This means a previously-deduplicated content string could be re-emitted as an empty string, silently changing behavior from the old code where the entire block was skipped.

[sharvan9515]

✅ Implements the stated intent

Intent: Fix raw tool call JSON appearing as message content by detecting tool-call-only assistant outputs and returning null instead of falling through to response attributes, and skip rendering the content area when message content is empty.

The diff implements all described fixes: parseAssistantContent in conversationMessages.ts now returns null for tool-call-only outputs, turnsToMessages creates assistant messages with empty content for tool-call-only turns, mergeEmptyTurns flushes pending tool calls onto the last result turn, and messagesPanel.tsx conditionally renders the content area only when message.content !== ''. Tests cover all new branches.

Findings (1): 1 medium · 📍 1 commented inline on changed lines

Severity	Location	Issue
🟡 medium	static/app/views/explore/conversations/utils/conversationMessages.ts:185	Deduplication Bypass — The hasAssistantContent check uses seenAssistantContent.has(turn.assistantContent) to deduplicate, but when hasToolCalls is true and assistantContent is null, the block is entered via hasToolCalls without adding anything to seenAssistantContent. If a subsequent tu…

📋 Basis of review

Examined control flow and logic changes in conversationMessages.ts and messagesPanel.tsx, including the new hasAssistantContent/hasToolCalls branching, the flush logic in mergeEmptyTurns, and the conditional render guard, together with the new test cases.

🔍 Needs human verification

1. Confirm at runtime that tool-call-only assistant turns render the tool call badges correctly without any content area, and that no visual regression occurs for turns that have both text and tool calls. 2. Verify that flushing pending tool calls onto the last result turn in mergeEmptyTurns does not cause duplicate tool call badges when the last turn already has tool calls from a prior merge. 3. Confirm that message.content !== '' (strict string check) correctly handles all possible content values returned by the updated turnsToMessages, including the FILTERED sentinel.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit c2b482b. Configure here.}

[cursor]

Assistant dedup bypassed with tools

Medium Severity

turnsToMessages now emits an assistant message when hasToolCalls is true even if that turn’s assistantContent was already deduplicated. A later turn with the same assistant text plus tool calls still pushes a full duplicate message (same content again), regressing the existing “deduplicates assistant messages by exact content” behavior.

 

^{Reviewed by Cursor Bugbot for commit c2b482b. Configure here.}