[Bug] Final assistant message of a turn sometimes never renders in the desktop UI — text is intact in session DB
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 22
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Title:
[Bug] Final assistant message of a turn sometimes never renders in the desktop UI — text is intact in session DB
Category: 其他 / 不确定 · Other / Not sure
Agent framework: ZCode Agent(自研)
Severity: 影响体验 · Major (works but degraded)
Reproducibility: 偶现 · Sometimes
Description:
When an agent turn ends with a long final text message after a block of tool
calls, that final message sometimes never appears in the desktop conversation
view. The user sees the short intro text emitted before the tool calls and
then the turn just ends — it looks like the assistant stopped mid-sentence.
Nothing is actually lost: the model generated the message in full, the CLI
core received and persisted it, and it renders fine after the session is
reopened. It is a display/hydration-layer failure only.
Steps to reproduce:
Observed twice in one session (no exact deterministic repro yet). Conditions
both times:
1. Agent performs a multi-step turn with several tool calls
(Bash / Write / Edit) interleaved with short text updates.
2. Turn ends with a long (1.5–2 KB) final text message.
3. Right after turn completion the client re-hydrates the session
(session.model.updated + session.reasoning_effort.updated +
zcode_protocol.session_snapshot.slow events within seconds of turn.completed).
4. Result: the final message is not drawn in the chat. Short single-shot
messages with no tool calls are never affected.
Expected behavior:
The final assistant message is rendered in the conversation view once the
turn completes.
Actual behavior:
The final message is missing from the UI (the user perceives a truncated
reply). Verification shows it exists everywhere except the rendered view:
- model I/O log (/root/.zcode/cli/rollout/model-io-<session>.jsonl):
full text present, finishReason=stop;
- core log (/root/.zcode/cli/log/zcode-2026-09-03.jsonl):
model.sdk.stream.completed → turn.completed, no errors;
- session DB (/root/.zcode/cli/db/db.sqlite, message.part):
message stored complete (1706 chars) with
semantics.uiVisibility = "visible";
- reopening the session redraws it from the DB.
ZCode version: v3.10.2 (desktop-attached-remote mode; zcode-server.cjs runs on the remote host)
Device / OS: Linux VPS (x64, kernel 7.0.0-29-generic), server runs as root; desktop client attaches over SSH
Evidence / logs:
- Session: sess_2ef031bf-e7f3-469e-9676-2cde54833605, 2026-09-03,
16:33–16:39 UTC. Turn completed 16:34:18 (turn.completed, toolCallCount=4);
snapshot.slow warnings at 16:34:22–16:34:26; user reports the missing
message at 16:39.
- Related hydration errors seen the same day for other sessions:
zcode_protocol.v4.gateway_error "Session not found: sess_..." (scope v4.hydrate)
at 14:31 and 14:45 — suggesting the v4 hydration path is fragile in 3.10.2.
- Workaround that helps users: switch the session away and back / restart the
app (history is redrawn from db.sqlite), or ask the agent to resend the
text as a compact plain-text message.
- Happy to attach the rollout/core log excerpts for the affected turn.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by correlating the turn.completed event with the session.model.updated, session.reasoning_effort.updated, and zcode_protocol.session_snapshot.slow events in the affected session. Compare the rendered conversation with message.part in db.sqlite and the model/core logs, then reproduce a post-turn rehydration. Done means the complete final assistant message remains visible without reopening the session.
Written by the indexing model from the issue text.
Assessment
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 50/100