Desktop: chat timeline shows messages out of order with concurrent sessions (empty session_id in terminal events)

[yangchangjiang]

Bug Report: Desktop chat timeline shows messages out of chronological order (concurrent sessions on same profile)

Environment

• Hermes desktop app (Electron), Windows 10
• Provider: DeepSeek (deepseek-v4-pro), profile: default
• Multiple concurrent sessions on the same profile (main chat + other chat sessions + cron jobs)

Symptom

In the desktop chat view, messages appear out of chronological order. A message the user just sent appears ABOVE older messages ("刚才问的，怎么排在上面了"). The user reports this happens repeatedly ("老是时间线对不上"), and as a workaround they re-send messages — which produces duplicates in the DB.

Evidence gathered from state.db + logs (2026-08-15)

1. Duplicate user messages from UI confusion: in one session (20260808_162500_414ff7), the same user message appears many times: 再次审计 x18, 报告发下 x5, 审计下carbrands x5. The user confirms they re-sent messages because the UI displayed them at wrong positions.

2. Empty session_id in terminal events: desktop.log contains 2,305 JSON-RPC events of type agent.terminal.output with "session_id": "" (empty string). Terminal output from background processes is emitted without session attribution; if the renderer keys its message store by session_id, these events can land in whichever session view is active/rendered, causing messages from other sessions (and their tool outputs) to appear inside the current conversation.

3. Concurrent interleaved sessions: at 17:16–18:00, three sessions were writing to the shared messages table simultaneously (20260623_233846_232bb8, 20260808_162500_414ff7, 20260708_225453_563966). One of them received a [CONTEXT COMPACTION] event at 17:16:53 while the user was chatting in another. The DB itself is correctly ordered by rowid/timestamp — the disorder is in the desktop renderer's view, not the store.

4. The session in question (20260623_233846_232bb8) is a long-running session (June 23 → Aug 15) with multiple compactions; the wrong-order symptoms correlate with compaction events and concurrent session activity.

Likely root cause areas (to investigate)

• agent.terminal.output events with empty session_id being dispatched to the active session view (or a shared store) instead of being dropped or routed by process_id.
• Renderer re-sorting messages by timestamp where second-level precision ties are broken unstably (several message pairs share the same second: e.g. rows 282813/282814 at 18:05:40, 282815/282816 at 18:05:50).
• Compaction notifications from one session triggering re-render/replay in another session's view.
• Out-of-band user messages (delivered mid-turn while the agent is streaming) being re-inserted at the wrong index on history replay.

Impact

• User cannot trust the conversation timeline; repeated re-sending pollutes sessions with duplicates.
• Risk of the model answering based on a wrongly-ordered context (e.g. stale "PV不准" appearing before a later question), degrading multi-session workflows.

Repro steps (approximate)

1. Open 2+ sessions on the same profile in the desktop app, one running long tool chains (background terminal processes emitting output).
2. Let one session trigger a context compaction while the other is streaming.
3. Send messages in quick succession (<1s apart) in the active session.
4. Observe messages landing above older ones / tool output from the other session appearing in the wrong view.

[CharlesR-sudo]

Additional evidence from a second reporter (2026-08-16), same environment class (Windows 11, DeepSeek provider, default profile, concurrent sessions + heavy cron load + repeated compactions).

New symptom confirmed live: repeated answer rendering

While diagnosing, the user observed the assistant's latest reply rendered twice ("你这次的答案内容重复了，等于回答了两次" — the answer content repeated, answered twice). This is a duplicate-paint symptom in the same session, not across sessions: one assistant reply visually appeared twice.

Second reporter's session facts (state.db verified)

• Session 20260815_184610_30d221: 471 of ~800 messages flagged compacted=1 (heavy compaction history).
• Message store is correctly ordered: id monotonic, timestamp monotonic, 0 inversions across 325 active messages. Disorder is renderer-side, not storage-side.
• Same as Desktop: chat timeline shows messages out of order with concurrent sessions (empty session_id in terminal events) #86890: DB fine, UI wrong.

Code-level candidate found (not mentioned in the original report)

preserveLocalAssistantErrors in apps/desktop/src/lib/chat-messages.ts:1185:

return [...mergedNextMessages, ...preserved]

When hydration (hydrateFromStoredSession, apps/desktop/src/app/contrib/wiring.tsx:352) fetches a backend snapshot that does not contain a locally-held assistant error message (e.g. an errored turn that never round-tripped), that preserved message — plus its preceding user turn — is appended to the END of the message array instead of re-inserted at its original position. Result: an older turn visually appears AFTER newer replies. Combined with the full-replace hydration in wiring.tsx:352 (state.messages := fetched snapshot), a stale/lagging snapshot can also overwrite the just-streamed latest reply.

Second candidate: completeAssistantMessage (apps/desktop/src/app/session/hooks/use-message-stream/index.ts:603-653) — the fallbackIndex reverse-scan path settles the final text onto the last non-hidden assistant row; under concurrent/duplicated message.complete events (plausible with empty session_id events from #86890/PR #86921) this can repaint the same reply or settle onto the wrong row.

Ctrl+R refresh — environmental, not a code bug

View menu has standard role: 'reload' (accelerator CommandOrControl+R, Electron default, apps/desktop/electron/main.ts:5341). User's Ctrl+R did nothing — most likely the accelerator is captured by another app/IME on Windows 11, or window focus. Workaround: View menu → Reload, or relaunch the app.

Suggested next steps

• PR fix(desktop): keep background terminal events in their owning session #86921 addresses only terminal-event attribution; these two code paths (preserveLocalAssistantErrors append, completeAssistantMessage fallback settle) are additional root-cause candidates for same-session ordering/duplication.
• Happy to test a fix branch if maintainers propose one.

[CharlesR-sudo]

Workaround verified (2026-08-16): full desktop app restart (quit completely, relaunch) resolves the out-of-order / duplicate-paint symptom immediately. Confirmed by the second reporter after restart — transcript ordering returned to normal. This supports the renderer-side stale-state diagnosis (data in state.db was always correctly ordered).