Persisted assistant diff output and tool activity can disappear after settled render

[thejakeyboy]

Bug description

After a WebUI assistant turn completes, content that was visible while/just after streaming can appear to disappear from the chat transcript. In the observed case, the user specifically requested Markdown diff blocks; the assistant produced a final answer with multiple fenced diff blocks, but after completion those diff boxes were no longer visible in the WebUI. Live tool-call messages/cards also appeared to disappear.

Important: the backend/session data still contained the content. This appears to be a frontend settled-render/reconciliation issue, not data loss.

Observed evidence

A local WebUI session was inspected through the API after the UI no longer showed the expected content. The API response still contained:

• A persisted assistant message with the requested diff-heavy final answer.
• Multiple Markdown fences, including fenced diff blocks.
• Session-level tool_calls metadata.
• Additional persisted role: "tool" transcript rows.

So the content existed in the API response but was not reliably visible in the completed transcript UI.

Steps to reproduce / scenario

1. In WebUI, ask the agent to perform a multi-step task with tool calls and request that edits be shown in Markdown diff blocks.
2. Agent streams progress, tool activity, and a final assistant answer with fenced diff blocks.
3. After completion / settled render / session refresh, inspect the visible chat transcript.
4. Some requested output that was visible earlier (diff boxes) may no longer be visible; live tool-call messages/cards also appear to be removed or not reconstructed in an equivalent settled view.
5. Fetching GET /api/session?session_id=<sid> shows the data is still in the session payload.

Expected behavior

• Final assistant Markdown that is persisted in session.messages should remain visible after stream completion and any active-session refresh.
• Requested fenced diff blocks should not disappear from the visible transcript.
• If raw role: "tool" messages are intentionally hidden, the settled Activity/tool-card view should preserve enough visible affordance/details that the user does not perceive tool activity as disappearing.

Actual behavior

• The persisted assistant answer still contains the requested diff blocks, but the WebUI view made them appear to disappear after completion.
• Raw tool rows are present in session.messages, and session-level tool_calls exists, but visible live tool activity can vanish or change substantially once done triggers settled rendering.

Relevant code paths / suspected areas

Recent commits in this area look relevant:

• v0.51.95 / PR fix: stream live tool callback events #2598: live tool callback event dedup / structured tool callback path.
• v0.51.94 / PR Recovery slice 1 from the closed reconciliation pr #2581 and followups: active-session external refresh/reconciliation.
• v0.51.95 / PR fix(session): dedupe messaging transcript timestamp variants #2607: transcript merge dedupe alignment.

Frontend render paths observed locally:

• static/messages.js done handler replaces local stream state with d.session.messages, clears live tool cards, sets S.busy=false, then calls renderMessages({preserveScroll:true}).
• static/sessions.js::refreshActiveSessionIfExternallyUpdated() can call loadSession(sid, {force:true, externalRefreshReason: ...}) after completion/focus/poll.
• static/ui.js::renderMessages() intentionally filters role === "tool" messages out of visible transcript:

const vis=S.messages.filter(m=>{
  if(!m||!m.role||m.role==='tool')return false;
  ...
});

and:

for(const m of S.messages){
  if(!m||!m.role||m.role==='tool'){rawIdx++;continue;}
  ...
}

Settled tool cards are then reconstructed from S.toolCalls / per-message metadata. The bug may be in one of:

• live stream DOM -> settled session DOM replacement;
• active-session external refresh overwriting the DOM with a different render window/scroll state;
• message windowing / “Load earlier messages” hiding content unexpectedly;
• raw tool rows being hidden while settled Activity reconstruction does not preserve the user-visible live evidence;
• Markdown render/post-processing for long diff-heavy messages after DOM replacement.

Debug notes

This was verified with direct API inspection, not just visual observation. The diff-heavy answer was still present in session.messages, so a fix should likely focus on frontend render/reconciliation/scroll/windowing rather than backend persistence.

---

I just want to say, however, how impressed I am with this project, and particularly how far it has come in the 2-3 weeks I've been using it.

[nesquena-hermes]

Summary

Thanks for the detailed report and especially for confirming the data is still present in GET /api/session — that rules out persistence/save bugs and narrows this to the frontend reconciliation path. Reading the relevant code, I think there are two candidate root causes that combine to produce the symptom you're seeing.

Candidate 1: stale session-HTML cache after external refresh

static/ui.js:5680-5692 keeps a per-session HTML cache:

if(sid&&sid!==_sessionHtmlCacheSid&&!INFLIGHT[sid]&&!hasTransientTranscriptUi){
    const cached=_sessionHtmlCache.get(sid);
    if(cached&&cached.msgCount===msgCount&&cached.renderWindowSize===renderWindowSize){
      inner.innerHTML=cached.html;
      _sessionHtmlCacheSid=sid;
      ...
      return;
    }
}

The cache key is (sid, msgCount, renderWindowSize). It does not hash the actual message content. So if refreshActiveSessionIfExternallyUpdated() at static/sessions.js:2080-2105 decides to call loadSession(sid, {force:true}) — and the new server payload has the same message count as before but mutated content — the next renderMessages() may serve cached HTML from before the diff blocks were finalized.

The cache hit only fires when sid !== _sessionHtmlCacheSid (i.e., on session switch), so this shouldn't trip on an in-place refresh by itself. But combined with focus/visibility-change calls that bounce sessions, it can.

Candidate 2: _isPreservedCompressionTaskListMessage and friends filter visible turns

static/ui.js:5709-5719:

const vis=S.messages.filter(m=>{
  if(!m||!m.role||m.role==='tool')return false;
  if(_isContextCompactionMessage(m)) return false;
  if(_isPreservedCompressionTaskListMessage(m)) return false;
  if(m.role==='assistant'){
    const hasTc=Array.isArray(m.tool_calls)&&m.tool_calls.length>0;
    const hasTu=Array.isArray(m.content)&&m.content.some(p=>p&&p.type==='tool_use');
    if(hasTc||hasTu||_messageHasReasoningPayload(m)) return true;
  }
  return m._statusCard||msgContent(m)||m.attachments?.length;
});

msgContent() at static/ui.js:4817-4822 strips non-text blocks:

function msgContent(m){
  let c=m.content||'';
  if(Array.isArray(c))c=c.filter(p=>p&&p.type==='text').map(p=>p.text||'').join('').trim();
  return String(c).trim();
}

For an assistant message where m.content is the structured-blocks array — e.g., [{type:'tool_use',...}, {type:'text', text:'```diff\\n…```'}] — the visibility filter passes because hasTu is true. But if the assistant turn loses its tool_use block during external refresh (because state.db stores tool calls under m.tool_calls rather than inline blocks), and the text block is empty for some reason, the visibility check at line 5719 (msgContent(m)) might evaluate falsy and the whole turn drops from vis.

That would explain "diff boxes were no longer visible in the WebUI" while the data lives in session.messages.

Candidate 3: tool card reconstruction lost on settled render

static/messages.js:2073-2076 (settled-restore path):

if(!hasMessageToolMetadata&&session.tool_calls&&session.tool_calls.length){
  S.toolCalls=(session.tool_calls||[]).map(tc=>({...tc,done:true}));
}else{
  S.toolCalls=[];
}

The _restoreSettledSession() path checks whether per-message tool_calls/_partial_tool_calls/tool_use are present on assistant messages, and if so, sets S.toolCalls=[] and relies on the fallback in static/ui.js:6047-6125 to rebuild cards from per-message metadata. That fallback only fires if(!S.busy && (!S.toolCalls||!S.toolCalls.length)) — so if a partially populated S.toolCalls survives from the live stream, the fallback won't run and live cards may not be rebuilt with the snippet payloads from role:'tool' messages.

This matches your "live tool-call messages/cards also appeared to disappear" observation: the live cards were rendered into #liveToolCards during streaming, but on settled render those live nodes are cleared by clearLiveToolCards() and the new cards are supposed to come from S.toolCalls. If the cards are session-level only and the per-message metadata path is taken, the reconstruction needs both the OpenAI-format m.tool_calls array and the matching role:'tool' result rows — which the API does return, but the frontend may be misclassifying which sessions take which branch.

Suspect commits (v0.51.93 → v0.51.95)

Bisecting recent merges in the active-session refresh / transcript merge area:

• 467ef33a feat(webui): reconcile external session updates — added refreshActiveSessionIfExternallyUpdated() and the 5s poll.
• dc5c8168 fix(webui): refresh active session on external sidecar updates — extended the refresh to externally-mutated sidecars.
• cb085020 fix(session): dedupe messaging transcript timestamps — refactored _merged_session_messages_for_display to use _session_message_merge_key; subtle behavior change around equal-content rows with different timestamps.
• 7c3dcce1 Stage 388: PR #2598 (avoid duplicate live tool events) — touched the live tool event path you specifically named.

Concrete next step

A short repro recipe + the GET /api/session?session_id=<sid> JSON for the affected turn (specifically the structure of messages[i].content for the assistant message that lost its diff blocks, and the tool_calls shape on it) would let one of the maintainers pin which candidate is the actual cause. Looking at:

1. Is messages[i].content a string with the diff fences inline, or an array of blocks?
2. Does the assistant message carry tool_calls, _partial_tool_calls, or content-array tool_use blocks?
3. Is session.tool_calls populated, and do its entries carry assistant_msg_idx?

The answer determines which of the three candidates is in play. My best guess from reading the code is candidate 2 (the visibility filter at static/ui.js:5709-5719 dropping a turn whose msgContent() evaluates empty), but candidate 1 (HTML cache serving stale rendering after an external refresh) is also plausible if the issue specifically happens on focus/tab-switch.

[Michael20070814]

I observed a similar behavior.

In my case, it happened while switching models and forking a previous conversation, then continuing the forked conversation. I am not sure whether these actions are the root cause.

The issue appeared around the time when context compaction/compression was triggered. At that point, the forked conversation disappeared from the UI, and some previously forked conversations also disappeared.

One thing worth mentioning is that I renamed the conversation while it was still working/generating. I am not sure whether this had any impact.

However, when I manually searched the JSON files, I was still able to find that conversation. I could also retrieve it successfully through the API using curl. So it seems the data was still persisted, but the UI did not show it correctly.

[thejakeyboy]

Thanks — I inspected the affected session payload locally and can answer the structural questions without posting the raw/session-identifying data publicly.

For the assistant message whose diff-heavy final answer disappeared from the settled UI:

• messages[i].role: assistant
• messages[i].content: plain string, not an array of blocks
• text length: ~12.8k chars
• Markdown fence count: 20
• fenced diff block count: 3
• messages[i].tool_calls: absent / empty
• messages[i]._partial_tool_calls: absent / empty
• inline content-array tool_use blocks: no, because content is a string

There was also a later persisted raw tool row with generated diff-like output:

• messages[j].role: tool
• messages[j].content: plain string
• text length: ~8.6k chars
• Markdown fence count: 9

At the session level:

• session.tool_calls is populated
• count: 42
• entries include assistant_msg_idx
• sample entry keys: args, assistant_msg_idx, name, snippet, tid

So for the vanished final assistant diff answer, candidate 2 seems less likely because the affected assistant message has non-empty string content and no structured block/tool_use shape. Candidate 1, render windowing/scroll anchoring, or Markdown/post-processing after settled DOM replacement seem more plausible for that part.

For the live tool activity/cards disappearing, candidate 3 still seems plausible: raw role: "tool" rows are present but intentionally hidden, live cards are cleared on done, and the settled cards need to be reconstructed from session-level/per-message tool metadata.

[ai-ag2026]

I opened a focused PR for the stale cached-HTML candidate from this issue: #2692

What it fixes:

• The session render cache was effectively keyed by session_id + message_count + renderWindowSize.
• If the backend/browser reconciled a settled session payload with the same messages.length but changed assistant content, tool-call snippets, reasoning/tool metadata, or compression-anchor metadata, switching back to the session could reuse older cached HTML.
• That matches the “API still contains the assistant diff/tool data, but the visible transcript looks like it disappeared after settled render/navigation” symptom class.

The PR keeps the cache, but adds a lightweight render-input signature and only reuses cached HTML when the actual transcript/tool-card inputs are unchanged.

Verification run locally:

• node --check static/ui.js
• node --check static/messages.js
• pytest tests/test_issue2613_render_cache_signature.py -q
• pytest tests/test_streaming_markdown.py tests/test_regressions.py -q
• pytest tests/test_sprint41.py -q
• Combined targeted run: 128 passed, 1 skipped

Scope note: this addresses the cached HTML / same-count mutation path. It does not claim to close every possible settled tool-card reconstruction issue discussed above, but it should remove one concrete way persisted final content can be hidden by an older rendered snapshot.