[Upstream #220] Duplicate/empty assistant responses and duplicated tool calls in active session

[quangdang46]

Mirrored from upstream 1jehuang/jcode — Issue #220 by @capt-marbles
Original state: open
Created: 2026-05-15T19:11:33Z · Updated: 2026-05-15T19:11:33Z
This issue is an auto-mirrored copy. Comments and edits here are local to quangdang46/jcode — do not expect them to propagate upstream.

---

Summary

During an active Jcode session, the UI/transcript began showing duplicate assistant messages and duplicate tool invocations. Some user-visible responses appeared empty or repeated, even though the underlying tool actions completed successfully.

This happened after a long session with many tool calls while working in /Users/awalker/trading-bot.

Symptoms observed

• Assistant progress/final messages appeared twice.
• Some responses looked blank/empty to the user.
• Tool calls were duplicated in the transcript, for example the same todo, bash, grep, and read calls appeared twice around the same action.
• The duplicated calls sometimes both executed, so this can be dangerous if the tool action is not idempotent.
• A paper-trading close operation was protected by explicit user approval and completed correctly, but surrounding messages/tool calls showed duplication artifacts.

Example from session

Around the sequence:

1. User: close CSCO paper position
2. Assistant progress message appeared twice.
3. The same close/verification bash blocks were emitted twice in the transcript, though only the successful output was shown once.
4. Later user asked: why the empty answers?
5. Assistant final answer was duplicated.

Also happened earlier with messages like:

• I’ll build the manual promotion bridge now... repeated twice.
• Built and committed advisory transition planning... repeated twice.

Expected behavior

• Each assistant message should render once.
• Each tool call should execute once unless explicitly invoked multiple times.
• If the UI loses a message, it should not show an empty assistant response.

Impact

Potentially high because duplicate tool execution can be unsafe for non-idempotent operations such as trading, file mutations, emails, or external API actions.

Environment

• OS: macOS arm64
• Jcode version: v0.12.1 f6ce4fd
• Working directory: /Users/awalker
• Date: 2026-05-15 UTC

Related issue

Possibly related to earlier session/runtime instability reported in #218.

Notes

I can provide a transcript excerpt or diagnostics bundle if useful.

[quangdang46]

Mirrored upstream report: duplicate / empty assistant responses + duplicate tool calls. Likely a streaming / replay race; needs reproduction on a specific provider + transport + interrupt sequence. Closing as not planned — re-open with a session id (or a recorded session) where it reproduces on this fork.

[quangdang46]

Mirror reports duplicate assistant messages and duplicate tool-call invocations. Almost certainly a streaming/replay race condition; without a recorded session or a reproducible interrupt sequence (specific provider, specific cancel, specific reload), there's nothing local to test against. Local fork has hardened the streaming/broadcast paths (see src/agent/turn_streaming_*.rs) since the report. Closing as not planned — please re-open with a session id (saved under ~/.jcode/sessions/) where it reproduces on this fork.

[quangdang46]

Implementation Plan

Scope

Duplicate / empty assistant responses + duplicated tool calls.

Hypothesis

Two paths:

1. Duplicate text: streaming finalize runs twice (e.g. on reconnect), pushes the same content twice into Session.messages.
2. Duplicated tool calls: tool registry`s deduplication-by-id is per-stream, but on reconnect we get fresh IDs that collide with the persisted ones.

Fix

1. Idempotency key on apply_assistant_message_finalize: keyed on (turn_id, content_hash) so re-applying is a no-op.
2. Tool-call dedup: keyed on tool_use_id from the provider; if seen in this turn, skip.

Files

• src/agent/turn_streaming_*.rs — finalize idempotency.
• src/agent/tool_dispatch.rs (or wherever tool registry lives) — dedup.

Tests

• finalize_idempotent_on_repeat
• duplicate_tool_use_id_dropped_with_warning
• streaming_reconnect_does_not_duplicate_visible_text

Estimated scope: M — 200 LOC + 3 tests.

[quangdang46]

Verified-fixed via PR #250 (merged). Tool dedup by tool_use_id at all 3 streaming accumulation sites prevents duplicate execution on reconnect.