fix(desktop): stop live-sync duplicating every message on send

[Kyzcreig]

Two-part fix for desktop messages rendering twice (display-only; DB clean). Server: message.complete now carries committed message_ids via _completed_turn_committed_ids(). Client: stamp predicate recognizes completed assistant rows (user-/assistant- prefix OR pending). Gated by RED→GREEN tests (6 server + 2 client). Upstream: NousResearch#64564.

[greptile-apps]

Greptile Summary

This PR fixes a desktop bug where every sent message was rendered twice (UI display only, DB was clean). The root cause was a two-part race: the client's completeAssistantMessage() cleared pending on the assistant row before markTurnComplete() ran the stamp, so the stamp predicate (which required user- prefix OR pending) silently skipped the assistant row; the post-completion poll then re-appended the committed row as a duplicate. The server half adds _completed_turn_committed_ids() to emit real DB row ids on message.complete; the client half widens the stamp predicate to also recognize assistant- prefixed ids.

• Server (tui_gateway/server.py): New _completed_turn_committed_ids() walks session history under history_lock, returns the last user row id and last assistant text row id (skipping tool-call rows), and attaches them to the message.complete payload as message_ids.
• Client (use-session-changes.ts): stampOptimisticTranscriptRows and optimisticTranscriptIds now treat any assistant--prefixed id as an optimistic id, regardless of pending state, so the completed assistant row is correctly re-keyed to its committed integer id before the poll runs.
• Tests: Six new Python tests cover the server helper; two new TypeScript tests cover the exact runtime ordering that triggered the bug (pending cleared before stamp) and the full end-to-end seam.

Confidence Score: 4/5

The fix is safe to merge. The duplication bug is real and reproducible and the changes target it precisely with matching tests on both sides of the stack.

The core change — widening the stamp predicate to accept assistant- prefixed ids — is correct and directly addresses the reported race. One design edge case exists in _completed_turn_committed_ids: when a user message has no _db_persisted_row_id, the function returns only the assistant id, and the client will assign that id to the user's optimistic row instead of leaving everything unstamped. The docstring describes the intent as 'no stamping' but the code delivers partial wrong-role stamping. This scenario requires a DB flush miss that should not occur in normal operation, so it is unlikely to surface in production, but it is worth verifying the ordering guarantee before the next multi-turn stress test.

tui_gateway/server.py — specifically the return value of _completed_turn_committed_ids when only one of the two expected ids is present.

Important Files Changed

Filename	Overview
tui_gateway/server.py	Adds _completed_turn_committed_ids() (new helper) and calls it under history_lock before _emit("message.complete", ...). The helper correctly skips tool-call rows and takes the last user/assistant text ids; a partial-list edge case (user id missing) could cause mis-aligned stamping on the client, though this is unlikely in normal operation.
apps/desktop/src/app/chat/hooks/use-session-changes.ts	Widens the stamp predicate in stampOptimisticTranscriptRows and optimisticTranscriptIds to recognise assistant- prefixed ids regardless of pending state — the direct fix for the duplication bug.
tests/tui_gateway/test_completed_turn_committed_ids.py	New test file with 6 unit tests covering the Python helper: normal case, tool-loop turn, empty-content tool row, missing row ids, non-int row id, and empty/invalid history. All scenarios are well-documented and correct.
apps/desktop/src/app/chat/hooks/use-session-changes.test.ts	Adds two targeted TypeScript tests: one for the exact runtime ordering (pending cleared before stamp) that caused the bug, and one full end-to-end seam test verifying no duplicate is added after a post-completion poll.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant C as Desktop Client
    participant S as TUI Gateway Server
    participant DB as Database

    C->>S: User sends message (optimistic ids: user-ts, assistant-ts)
    S->>DB: Flush messages (_db_persisted_row_id stamped: 100, 101)
    Note over C: completeAssistantMessage()<br/>clears pending on assistant-ts row
    S->>S: _completed_turn_committed_ids(history) → [100, 101]
    S->>C: "message.complete {message_ids: [100, 101]}"
    Note over C: markTurnComplete() runs stampOptimisticTranscriptRows()<br/>user-ts → 100, assistant-ts → 101<br/>(assistant-ts matched by assistant- prefix, not pending)
    C->>S: "session.changes poll (since=99)"
    S->>C: "[{id:100,user},{id:101,assistant}]"
    Note over C: appendFetchedMessages: 100 and 101 already in renderedIds → NO DUPLICATES

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant C as Desktop Client
    participant S as TUI Gateway Server
    participant DB as Database

    C->>S: User sends message (optimistic ids: user-ts, assistant-ts)
    S->>DB: Flush messages (_db_persisted_row_id stamped: 100, 101)
    Note over C: completeAssistantMessage()<br/>clears pending on assistant-ts row
    S->>S: _completed_turn_committed_ids(history) → [100, 101]
    S->>C: "message.complete {message_ids: [100, 101]}"
    Note over C: markTurnComplete() runs stampOptimisticTranscriptRows()<br/>user-ts → 100, assistant-ts → 101<br/>(assistant-ts matched by assistant- prefix, not pending)
    C->>S: "session.changes poll (since=99)"
    S->>C: "[{id:100,user},{id:101,assistant}]"
    Note over C: appendFetchedMessages: 100 and 101 already in renderedIds → NO DUPLICATES

Loading

_{Reviews (1): Last reviewed commit: "fix(desktop): stop live-sync duplicating..." | Re-trigger Greptile}

[greptile-apps]

Partial ID list causes misaligned stamping

When only the assistant row has a _db_persisted_row_id (e.g. user message not yet flushed), the function returns [assistant_id] instead of []. The client's stampOptimisticTranscriptRows then stamps in position order — so user-<ts> (the first optimistic row) gets assigned assistant_id, while assistant-<ts> is left with its optimistic id and later dropped by the poll. The docstring says "partial or absent list simply means no stamping this turn", but the partial [assistant_id] path causes wrong-role id assignment rather than a clean no-op.

Returning [] instead of a partial list when either required id is missing matches the stated intent and avoids the mis-stamp. The test test_missing_row_ids_are_skipped asserts [101] today, so this is a documented design choice — but the client-side consequence of receiving a one-element list was not validated there.