fix(desktop): show edited head content in thread panel

[salman1993]

Why

Fixes #6886. In the channel timeline an edited message shows its newest body, but opening its thread panel showed the stale pre-edit body until the async thread-aux backfill landed (and permanently if it raced or missed).

Root cause

desktop/src/features/messages/lib/independentThreadPanel.ts built events = [head, ...replyEvents], discarding the head's aux overlay events (edits kind:40003, deletions, reactions) already present in the channel window. formatTimelineMessages only applies an edit when the edit event sits in the same array as its target, so the thread head relied solely on withThreadAux to re-supply it.

What

• Carry the head's non-content aux events (via !isTimelineContentEvent) from the channel window into the thread head's event array, deduped against replyEvents by id.
• Thread head is now byte-identical to the main timeline the instant the thread opens, independent of the async aux fetch.
• Restricted to non-content kinds so reply content rows never leak in.

Tests

• Unit regression independentThreadPanel.test.mjs (6 cases): red pre-fix ("two PRs"), green post-fix ("these PRs").
• e2e thread-head-stale-edit.spec.ts: delays thread-replies aux to force the channel-window-vs-thread-aux divergence, then opens the thread via the reply button and asserts the panel head shows the edited body. Verified red pre-fix (stale message-thread-panel head), green post-fix.
• Full desktop unit suite: 5562 pass / 0 fail. biome + tsc --noEmit clean.

Origin: Buzz channel fix-reply-thread-old-view-bug (#464b982f-fc05-42c8-918f-409e1f05a1df).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2c207987ae

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[salman1993]

Tested through the Buzz app (desktop Playwright harness) at head 28a00e9. Thread-aux delayed 4s, thread opened via the reply button — the thread head shows the edited 3-PR body immediately, matching the main timeline, while replies are still loading. Bug fixed.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

P1 — Make the pre-backfill E2E proof deterministic. The test delays get_thread_replies by 4 seconds, but both assertions use Playwright’s 5-second auto-retry window. On the old implementation, the panel can initially show the stale body, then the delayed relay response (which includes the root edit) arrives inside that retry window and the positive assertion passes. Navigation/opening time consumes part of the four seconds, so load makes the false-green path more likely. Gate the mocked response until after checking the initial panel state, or otherwise assert synchronously/with a deadline guaranteed to precede release. The unit test pins the pure helper, but this E2E is the only proof that the real async UI opens with the channel-window overlay rather than healing later.

Production logic at 28a00e9a518b1299991b96ebff4fa08a7c4222c2 otherwise looks sound: it carries direct head aux, includes one-hop deletion closure, filters content rows, and deduplicates against relay-provided thread aux.

[salman1993]

Addressed the P1 (make the pre-backfill E2E proof deterministic).

The 4s threadRepliesDelayMs was a self-healing timer inside Playwright's 5s auto-retry window, so the delayed aux backfill could land mid-assertion and false-green on the buggy code. Replaced it with a manual gate: new deferThreadReplies mock option holds every get_thread_replies response open until the test calls __BUZZ_E2E_RELEASE_THREAD_REPLIES__() (mirrors the existing deferLinkPreviewMetadata / RELEASE_GET_EVENT queue pattern). The thread-aux backfill provably cannot land before the head assertion runs.

The spec now:

1. asserts the head shows the edited body while the fetch is verifiably held (a __BUZZ_E2E_THREAD_REPLIES_PENDING__ poll guards against the fetch never having been dispatched, so the assertion can't pass by the request being absent);
2. releases the gate and re-asserts the head stays edited (dedup path).

Verified red/green: reverting the production headAux carry in independentThreadPanel.ts makes the spec fail deterministically at the head assertion (receives the stale "these two PRs?"); with the fix it passes. tsc clean; 8/8 independentThreadPanel unit cases green.

Pushed as d051350.

Updated by Leo 🤖

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

The former P1 is resolved: the manual deferThreadReplies gate now prevents the aux backfill from landing before the decisive assertion, and the pending-request check proves the gated fetch was actually dispatched.

Blocking CI/code issue — format the changed E2E file. Desktop Core fails in just desktop-check because Biome would reformat the page.evaluate call at desktop/tests/e2e/thread-head-stale-edit.spec.ts:160-166. Apply the formatter and push the result. This is mechanical, but the current head does not pass the repository’s required desktop check.

Non-blocking: the post-release assertions can run before the released response is consumed, so they do not independently prove the post-backfill transition. The pure-helper dedup test covers that merge contract, so this does not block the fix.