Desktop search opens replies without parent thread or channel context #6146

Activity

1. cmyk commented on Aug 18, 2026

   

   cmyk

   on Aug 18, 2026

   Author

   More actions

   Clicking a macOS notification for a direct or nested reply must open the complete parent/root thread, highlight the notified reply, and provide channel/parent navigation even when the notification payload lacks an explicit threadRootId.
2. Giszmo commented on Sep 15, 2026

   

   Giszmo

   on Sep 15, 2026

   More actions

   Reproduced on main (051c3a2) and traced. This is the same defect as the notification case, and the open PR #7452 fixes both — but it is written and tested only as a notification fix, so the link to this issue is easy to miss.

   Mechanism. Search results and notifications share one navigation path: openSearchHitWithNavigation → cacheSearchHitEvent + goChannel → ChannelRouteScreen. buildSearchHitEvent (desktop/src/app/navigation/searchHitEventCache.ts) projects a hit into a RelayEvent whose only tag is ["h", channelId] — no e reply tags, because the search response carries no thread root at any layer (SearchHit in crates/buzz-search/src/query.rs, SearchHitInfo in desktop/src-tauri/src/models.rs, fromRawSearchHit in desktop/src/shared/api/tauri.ts). ChannelRouteScreen splices that projection into the timeline at mount, so useChannelRouteTarget sees targetMessage.parentId === undefined, takes the root-message branch, opens the matched reply as its own thread head, and records it in handledThreadRouteTargetRef — after which hydrating the real event can no longer repair the selection. That is the "No replies in this branch yet" panel described above.

   Evidence. I added a search-path regression to desktop/tests/e2e/navigation.spec.ts — emit root → sibling → parent → nested reply into a mock channel, hold the target's get_event with __BUZZ_E2E_DEFER_GET_EVENT__, search for the nested reply, click the result, release hydration, then require the root and both ancestors in the thread panel:

   • on main (051c3a2) it fails, with the thread head being the matched reply itself ("Nested searchable reply");
   • on fix(desktop): preserve full thread context when opening reply notifications #7452 (031df39) it passes, alongside that PR's notification case.

   Test case (mirrors the one in #7452)

   test("search result hydration opens the full thread instead of the cached reply", async ({
     page,
   }) => {
     await page.goto("/");
     await page.getByTestId("channel-general").click();
     await expect(page.getByTestId("message-input")).toBeVisible();
     const targetId = await page.evaluate(() => {
       const emit = window.__BUZZ_E2E_EMIT_MOCK_MESSAGE__;
       if (!emit) throw new Error("Mock message fixture unavailable");
       const input = {
         channelName: "engineering",
         pubkey:
           "953d3363262e86b770419834c53d2446409db6d918a57f8f339d495d54ab001f",
       };
       const root = emit({ ...input, content: "Search context root" });
       emit({
         ...input,
         parentEventId: root.id,
         content: "Sibling reply retains context",
       });
       const parent = emit({
         ...input,
         parentEventId: root.id,
         content: "Parent reply retains context",
       });
       const target = emit({
         ...input,
         parentEventId: parent.id,
         content: "Nested searchable reply",
       });
       window.__BUZZ_E2E_DEFER_GET_EVENT__ = target.id;
       return target.id;
     });
   
     await page.keyboard.press("ControlOrMeta+k");
     await page.getByTestId("search-dialog-input").fill("Nested searchable reply");
     const hit = page.getByTestId(`search-result-${targetId}`);
     await expect(hit).toBeVisible();
     await hit.click();
     await expect(page.getByTestId("chat-title")).toHaveText("engineering");
     // Hold the authoritative lookup until navigation has committed. The cached
     // search hit has no reply tags and must not become the selected thread.
     await page.evaluate(() => window.__BUZZ_E2E_RELEASE_GET_EVENT__?.());
     const thread = page.getByTestId("message-thread-panel");
     await expect(thread.getByTestId("message-thread-head")).toContainText(
       "Search context root",
     );
     await expect(thread).toContainText("Sibling reply retains context");
     await expect(thread).toContainText("Parent reply retains context");
     await expect(thread.locator(`[data-message-id="${targetId}"]`)).toContainText(
       "Nested searchable reply",
     );
   });

   Two parts of this report that #7452 does not cover, in case they should be split out:

   1. The breadcrumb and explicit Open parent thread / Back to channel affordances. fix(desktop): preserve full thread context when opening reply notifications #7452 restores the thread, not the navigation affordances.
   2. When the lookup fails (offline, or the event is not retrievable) fetchRouteEvent returns null and the tag-less projection is inserted on its own, so the isolated-branch behaviour returns. The belt-and-braces fix is to carry the thread root in the search hit itself, which would also let resolveSearchHitDestination stop passing threadRootId: null for every message hit.