[Bug]:Assistant replies intermittently disappear from chat; next turn loses context (orphaned branch via stale parent_message_id)

[Vincent-LJP]

Do you need to file an issue?

• I have searched the existing issues and this bug is not already filed.
• I believe this is a legitimate bug, not just a question or feature request.

Describe the bug

In the unified chat workspace, after an assistant reply finishes streaming, the reply sometimes disappears from the conversation view. If I then send another message, the model answers as if it only saw the first turn of the conversation. Switching to another conversation and back makes the missing replies reappear, and subsequent context works again.

Environment

• DeepTutor version: 1.5.4 (pip install, deeptutor start)
• OS: Windows 11
• Browser: Chrome (latest)
• Deployment: local, single user

Steps to reproduce

1. Chat normally for several turns.

2. Occasionally, right after streaming completes, the assistant's reply disappears from the view.

3. Send another message -> the model responds using only the earliest turn(s) as context.

4. Switch to another conversation and back -> the full history reappears.

Investigation / likely root cause

I inspected the local data/user/chat_history.db. All messages (user + assistant) are persisted correctly — nothing is lost server-side, and all turns have status = completed.

However, several user messages have parent_message_id pointing to the previous user message instead of the assistant reply that came in between (anonymized real data):

• msg 168 (user): parent = 166 (previous user msg), expected 167 (the assistant reply in between)

• msg 172 (user): parent = 170 (previous user msg), expected 171 (the assistant reply in between)

• msg 180 (user): parent = 178 (previous user msg), expected 179 (the assistant reply in between)

Consequences:

1. Context loss: _get_message_path_sync in deeptutor/services/session/sqlite_store.py builds the LLM context by walking the parent_message_id chain from the current message. Orphaned assistant replies are excluded — e.g. when msg 168 was sent, the model only saw the first round + the new question.

2. Display loss: the web UI renders only the active branch, so the orphaned reply is invisible until a full reload (switching conversations) re-fetches the session from the DB.

The frontend sends parentMessageId with each new message (verified in the compiled web bundle), so it appears the frontend sometimes fails to adopt the completed assistant message as the active leaf after streaming finishes, then attaches the next user message to a stale parent — creating an orphan branch.

Expected Behavior

After a turn completes, the assistant reply stays visible and becomes the active leaf; the next user message's parent_message_id points to it.

Related Module

Frontend/Web

Configuration Used

• Install: pip install deeptutor==1.5.4
  • OS: Windows 11
  • LLM provider/model:
  • Otherwise default settings

Logs and screenshots

No response

Additional Information

• DeepTutor Version: 1.5.4
• Operating System: Windows 11
• Python Version: 3.11.15
• Node.js Version: v24.15.0
• Browser (if applicable): Edge
• Related Issues: fix: prevent sending messages while AI is streaming response #674

[ImproveRei0]

same，seems a new bug in v1.5.4
(I updated the system from v1.51)

[pancacake]

Thanks — the parent_message_id table in your report was what made this findable.

One root cause is fixed on dev (2faaef9e). Optimistic rows were minted with -Date.now() at UnifiedChatContext.tsx:349 (user row) and :435 (assistant placeholder), and those two dispatches are back-to-back — so they routinely landed in the same millisecond and shared one id. reconcileTurnIds keys its optimistic→persisted remap by id, so when done arrived both rows collapsed onto the user's persisted id. That reproduces every symptom you described, exactly:

• the next turn's wire parent_message_id becomes the previous user message (your 168→166, 172→170, 180→178);
• buildVisiblePath then sees two children under that id and picks the newer optimistic one, so the reply drops out of view;
• a session switch re-fetches from the DB, where the ids were always right, and it reappears.

It surfaced in 1.5.4 (@ImproveRei0's observation is consistent): before 308a0606 the client refetched the whole session after each turn, which overwrote the collision. Ids are now minted from a single generator that never repeats.

A second, independent path is still open, found by @AmirF194 in #706: the done event carrying the ids is published but never persisted, so a client that reconnects after the turn completed gets a synthesized done with no ids and never reconciles at all. I verified that ordering in turn_runtime.py (the flush at :1724 runs before the publish at :1745). Keeping this issue open until that one lands too.

[JonbinC]

I can reproduce the same main-workspace symptom on an arm64 Docker deployment (DeepTutor v1.5.1, public HTTPS reverse proxy; the proxy is not involved in the data path).

A concrete persisted chain from data/user/chat_history.db was:

27 user      parent=NULL
28 assistant parent=27
29 user      parent=28
30 assistant parent=29
31 user      parent=29   # should have been parent=30
32 assistant parent=31

The UI therefore chose the newer branch 29 -> 31 -> 32 and hid the valid earlier reply 30, exactly as described in this issue. All four user/assistant messages and both turns were persisted successfully.

I applied a local hotfix to the compiled home-chat bundle: for ordinary follow-ups, it now omits parent_message_id entirely and lets the backend auto-append to the latest persisted message. Explicit edit/branch operations still provide a parent id. This prevents the bad branch shape in my deployment.

I also found a separate Partner chat UI race (not the main-chat issue): the Partner component starts an async history hydration and unconditionally does an equivalent of setMessages(history). If the user sends a message before that request resolves, WebSocket events append live messages first, then the stale history response replaces the whole local list. The backend JSONL conversation remains intact. A generation/version guard or merge/dedupe by stable message/turn id is needed there.

Happy to provide a small diff, but please note the home-chat issue is already covered by #698; this comment is intended as an independent reproduction plus the Partner-specific related race.

[pancacake]

Thanks for your comments~ feel free to check v1.5.9