Missing replies in thread view after replying to non-latest messages

[Voisens]

Description: When an agent replies to a message that is not the most recent in a thread, the reply is delivered and visible in the agent's message history, but does not appear in the thread panel UI on the right side.

Steps:

1. Start thread with message A
2. Agent replies to A (appears in thread)
3. User adds message B to same thread
4. Agent replies to B
5. Agent's reply to B is missing from thread panel UI (though it exists in relay)

Expected: All replies appear in thread panel, chronologically ordered
Actual: Replies to earlier messages become invisible in UI

Environment: Buzz Desktop

[iroiro147]

Hi — I'd like to take a crack at this. Plan: confirm in trace whether the thread panel's reply aggregation drops agent replies anchored to non-latest messages (relay has them per the report), then make a minimal desktop-side fix with a regression test. Will link a PR back here.

[iroiro147]

Hi — I traced this end-to-end in the desktop tree-build and found two layered surfaces that together explain the symptom exactly ("reply exists in relay, invisible in the thread panel UI").

Root cause (mechanism)

When the agent anchors a reply to a non-latest message (per your Step 4, parent=B, depth=2), the reply itself:

• is delivered over the live subscription into threadRepliesKey(channelId, A) (desktop/src/features/messages/hooks.ts:286-289),
• is returned by get_thread_replies(A) on the backend (crates/buzz-db/src/thread.rs:345 + nested-depth regression test at :1230),
• and IS present in the thread panel's input set via useIndependentThreadPanel → buildIndependentThreadPanel (desktop/src/features/messages/lib/independentThreadPanel.ts:19-24).

But it is never rendered because:

Surface 1 — collapsed branch swallows it. expandedThreadReplyIds is empty at open (ChannelScreen.tsx:145-147) and nothing re-adds message B's id (the "expand parent" write only happens on the user's own send inside the same panel, useChannelPaneHandlers.ts:291-301). In threadPanel.ts:338-357 (appendExpandedReplies), a depth-1 child that is NOT expanded renders as a MessageThreadSummaryRow and recursion stops — so the depth-2 reply under B is never pushed into visibleReplies. The result is a tiny "1 reply" collapsed row on B that the user has to notice and click.

Surface 2 — unread badge shows 0 even while the branch has unread content. The badge factory computeThreadReplyUnreadCounts (desktop/src/features/channels/lib/threadReplyUnreadCounts.ts:48-71) is descendant-aware, but its input is timelineMessages — the channel-window projection only. A fresh depth-2 reply that lives solely in the threadRepliesKey cache (live-appended, not yet reconciled into the window) is absent from unreadReplyIds, so stats.get(B).unreadDescendantCount = 0 and the collapsed row shows no badge at all. Additionally B itself is the viewer's own message so it was marked read when revealed.

Combined, the agent's depth-2 reply is invisible AND signal-free — matching the report.

Two candidate fixes (asking for your preference before I open a PR)

(a) Auto-expand ancestors of fresh depth-2+ replies when the panel opens — in ChannelScreen / useChannelPaneHandlers adjacent to handleOpenThread, walk each incoming depth-≥2 reply's parent chain and add the intermediate ids to expandedThreadReplyIds. Surgical, preserves the collapsed-by-default UX for established branches, makes the new reply visible immediately. Small regression test pinning "collapsed B + unread depth-2 R + empty expansion set must auto-expand B".

(b) Union threadReplyEvents into the unread-state input at the computeThreadReplyUnreadCounts call site (or inside it), so even when the branch stays collapsed the badge surfaces the unread depth-2 reply (surface 2 only). Keeps collapse-by-default intact; user still has to click to read, but at least sees the count.

(a)+(b) is the conservative "both signal and visibility" combo. I'd lean toward (a)+(b) together for #3799 since the report calls out the UI itself missing the reply — a badge-only fix still requires the user to go hunting. But either touches expansion policy, so I want your direction before writing the patch.

I have a local worktree ready and can push a branch + PR within ~30 min of your call. Will also include a regression test in threadPanel.test.mjs (or threadReplyUnreadCounts.test.mjs for (b)) covering the exact geometry.

[iroiro147]

Update: both proposed surfaces are implemented and opened as PR #3856.

The two root-cause surfaces

Surface	Mechanism	Why the reply is invisible
render	Panel opens with expandedThreadReplyIds empty (ChannelScreen.tsx React state). A depth-1 child carrying any descendant renders as a collapsed MessageThreadSummaryRow; appendExpandedReplies (threadPanel.ts) stops recursion at it → the depth-2 reply never lands in visibleReplies.	Present in threadRepliesKey, but never mounted in the panel.
badge	computeThreadReplyUnreadCounts (useChannelUnreadState.ts) builds its input from the channel-window projection only (timelineMessages). A fresh depth-2 reply lives in threadRepliesKey but not in that window, so the descendant-aware subtree walk never reaches it.	Collapsed ancestor shows unreadDescendantCount = 0 — no signal.

Same logical bug at two stages: the open thread's fetched reply set ([head, ...replyEvents]) is richer than the channel-window projection that seeds panel state, and neither surface reconciled against it.

What shipped

• scope-a — pre-expand at open. computeInitialExpandedReplyIds (pure, in threadPanel.ts) computes the minimal intermediate-ancestor set of every depth-≥2 reply in the fetched thread set. useThreadPanelInitialExpansion (new hook, extracted out of ChannelScreen to respect the desktop file-size ratchet) seeds expandedThreadReplyIds once per opened head — union-only, idempotent, and never overrides a later manual expand/collapse.
• scope-b — unread badge counts beyond the window. unionScopeMessages (pure, in threadReplyUnreadCounts.ts). useChannelUnreadState feeds the badge computer a union of the channel-window projection and the open thread's full fetched set via a widened directReplyIdsByParentId memo used only by this path — every other unread reader stays window-scoped.

Verification (3879/3879 green)

• threadPanel.test.mjs — 6 new cases: seed surfaces the depth-2 reply on open; depth-1-only threads stay collapsed; unread-scoped filtering expands only the unread branch; depth-3 chain pins every intermediate parent; cycles/missing parents tolerated without hanging; buildThreadPanelData + seed integration.
• threadReplyUnreadCounts.test.mjs — 3 new cases: unionScopeMessages dedup/order/identity; a depth-2 reply outside the window is counted against the collapsed ancestor; negative control pins the pre-fix unreadDescendantCount = 0.
• Full desktop suite 3879/3879; pnpm check (biome, file-size ratchet, px-text, pubkey-truncation) clean.

PR: #3856 · branch fix/thread-replies-nonlatest-3799-dco · SHA da8385b7 · DCO ✅.

(A first PR #3855 was opened against the same tree but closed immediately because its sole commit lacked the required DCO sign-off.)

[Voisens]

Thanks for the fix, appreciate the quick root-cause + PR!