fix(link-preview): reliably render previews sent right after they resolve

[tellaho]

Overview

Category: fix
User impact: Link previews no longer disappear when a message is sent while preview metadata or media is still settling. Fast Enter, rapid Enter, and confirmed-draft auto-send now preserve the preview without duplicate sends or stale tags.

Problem: The composer could look ready before its sender-authored snapshot tag existed. Send paths could then race preview resolution/upload, while debounced preview state could attach a tag for a URL that had already been removed. The same timing also caused confirmed-draft auto-send to be consumed without sending.

Solution:

• Debounce preview resolution to avoid card flicker while typing, then disable every submit path while a supported external preview settles. A 2-second escape cap still permits a bare-link send if resolution stalls.
• Keep submit synchronous: acquire a composer-local lock before asynchronous send work, read ready tags from the live URL set, and reject Enter/form submits while a snapshot is pending.
• Retry confirmed-draft auto-submit until preview settling clears, then submit exactly once.
• Upload thumbnail and favicon independently. A failed upload shows a toast and degrades to the surviving media (or text-only) rather than leaving the card spinning.
• Exclude message-edit mode from preview resolution, upload, and Save gating. Edit-time preview snapshots remain follow-up feat(composer): support link previews on message edit (Option B, follow-up to #5245) #5273.
• Canonicalize fragment-bearing URLs for preview lookup/snapshot identity while preserving the original fragment links in message text.

Link preview state walkthrough

Captured using PR #5245's actual public Open Graph metadata and artwork. The deterministic E2E bridge controls only upload timing so the transient disabled state can be captured reliably.

State	Expected behavior	Screenshot
1. Snapshot upload pending	The real PR preview is visible, but Submit remains disabled until its sendable snapshot tag is ready. Click and Enter cannot send a bare link during the settling window.
2. Snapshot ready	Once snapshot upload settles and the tag is ready, the same preview remains and Submit becomes active.
3. Message sent	The sent event carries the snapshot tag and renders the PR title, description, and artwork inline instead of degrading to a bare URL.

Regression coverage

• Enter during metadata resolution or snapshot upload cannot send early.
• Paste-and-immediate-Enter sends after settling; rapid Enter submits exactly once.
• Confirmed-draft auto-send waits for settling and fires exactly once.
• Removed/replaced URLs cannot leak stale snapshot tags or media refs.
• Thumbnail upload failure toasts and sends with the surviving favicon.
• Edit mode does not resolve/upload previews or gate Save.
• Fragment variants share a canonical preview while original fragment links remain clickable.
• Existing ready-preview, suppression, bare-link fallback, and multi-preview behavior remains covered.

Reproduction steps

1. Open a channel and paste a supported external URL into the composer.
2. Press Enter immediately, before preview metadata/media finishes settling.
3. Before this fix, the event could be sent without its preview snapshot (or confirmed-draft auto-send could be lost). With this fix, submit waits behind the disabled state and fires once with the matching snapshot tag.
4. Remove or replace the URL and press Enter inside the debounce window. The sent event contains tags only for URLs still present in the submitted content.

Validation

All required PR checks are green, including Desktop Core, Desktop Smoke E2E shards, Desktop E2E Integration shards, macOS build, security checks, and DCO.

[air3ijai]

A quick Slack/Buzz comparison - https://github.com/block/buzz/pull/3818

Slack

Buzz

[DocNR]

Still reproduces on Desktop 0.5.7 (macOS 26, self-hosted relay).

Data point on the size of the race window: my relay is self-hosted and reached over Tailscale, so the snapshot upload leg is slower than a hosted setup — the gap between "card looks resolved" and "snapshot tag exists" is correspondingly wider. Pasting a link and waiting ~2s before Enter lands the preview; hitting Enter straight away reliably does not. Matches the mechanism described above.

Possibly a second symptom of the same root cause: when send happens inside that window, the preview card is also not cleared from the composer — the message posts as a bare link and the card stays sitting in the input box afterwards. If the card's "done" state is what drives teardown, a card that never genuinely resolved would explain both halves. Happy to file that separately if it's unrelated.

[tellaho]

Thanks for the self-hosted angle @DocNR will keep poking at this

[wesbillman]

Reviewing on Wes’s behalf.

Blocker — draft auto-send is consumed while preview gating is pending, so the confirmed draft is never sent.

This change explicitly adds hasPendingLinkPreviewSnapshotsRef.current to submitMessage as a guard for “Enter, form, auto-submit.” But the auto-submit effect is a one-shot: it clears ?autoSend first, schedules exactly one submitMessageRef.current() call, and never retries. A draft containing a supported HTTPS link will normally still be inside the new 350 ms debounce/metadata/upload settling window when that zero-delay callback runs. submitMessage therefore returns at the new pending-snapshot guard; the trigger has already been cleared and the mount-only effect cannot fire again. The user confirmed “Send message,” but nothing sends.

Please make auto-submit wait/retry until preview settling finishes (or the two-second escape cap fires) before consuming the trigger, while preserving the loop-prevention invariant. Add coverage that drives the actual draft auto-send path with a supported link and proves exactly one message is eventually sent. The current preview tests only exercise manual button/Enter paths.

The PR description also needs updating to match the final implementation: it still says Send awaits a capped in-flight upload and that getReadyTags became async, but head 90619924f instead disables/guards submission until readiness and keeps getReadyTags synchronous.

I did not rerun CI-equivalent suites locally; existing CI is green at this head, but it does not cover this one-shot auto-send transition.

[wesbillman]

Adversarial review at exact head 90619924f. I found a stale-tag race caused by using the debounced candidate set as the submit identity. This is distinct from the draft auto-submit blocker already reported by another reviewer. I did not duplicate CI-equivalent suites locally; CI is green, and the finding follows from the synchronous submit path versus the intentional 350 ms debounce.

[tellaho]

@wesbillman both blockers now have regression tests, pushed as 58f65ed.

Blocker A (auto-send drop) — e2e + unit
Extracted the mount-effect logic into a pure scheduleSettleGatedAutoSubmit helper: poll while a snapshot is pending, then submit exactly once when settling clears (never zero, never twice). New e2e drives the real Drafts-panel Send→confirm flow via in-app nav (page.goto to /channels/... 404s under the static test server) and asserts exactly one send carrying the resolved snapshot tag. New fake-timer unit test proves the drop-guard: waits while pending, sends once on clear, cleanup cancels the orphan send.

Blocker B (tag leak) — unit
Extracted selectSubmitTags, keyed off the LIVE href set (never the debounced one), and rewired getReadyTags to it. Unit test proves a deleted URL's tag is never emitted, a replacement link emits only its own tag, live order is preserved, and suppression emits the "none" marker.

Full disclosure on Blocker B: I wrote it as an e2e first and it was flaky — sending inside the 350ms debounce window didn't reliably fire a submit headless, so it caught nothing. Killed it, replaced with the deterministic unit test above. Both the leak-guard and drop-guard cases were verified to fail on pre-fix behavior, so they actually catch the bugs.

Bonus: extracting the two helpers also pulled MessageComposer.tsx back under the file-size cap.

Green locally: full unit suite 4595 passed, Blocker A e2e passed, typecheck + biome + file-size clean.

[wesbillman]

Re-reviewing on Wes's behalf at exact head 6ec255a6050fa40a85a380e3d82eda250b5aae46.

The two prior code blockers are fixed:

• scheduleSettleGatedAutoSubmit now retries the real one-shot draft auto-send while snapshot settling is pending, submits once after readiness/cap expiry, and cancels its timer on unmount. The new Drafts-panel E2E exercises the production confirmation/navigation path and asserts exactly one send with the snapshot tag.
• Submit-tag selection now intersects the ready-tag map with the live candidate hrefs via selectSubmitTags, so a removed URL lingering in debounced state cannot leak its snapshot metadata/media references. Deterministic unit coverage exercises removed and replaced hrefs.

Remaining blocker — update the PR description to describe the code actually being reviewed. It still says getReadyTags became async, Send awaits it, and SNAPSHOT_SEND_WAIT_CAP_MS caps the wait. None of that exists at this head. The implementation uses synchronous tag selection plus hasPendingSnapshots/SNAPSHOT_SETTLE_DISABLE_CAP_MS submission gating, and now includes a settle-gated draft auto-submit scheduler. The reproduction/test summary is stale for the same reason. Please rewrite the Solution, file-change details, and verification text to match the shipped design.

Focused local regression tests passed 9/9 at this exact head. I did not duplicate the broad CI suite; GitHub's Desktop Core job has already passed lint, unit tests, build, clippy, check, and Rust tests and is still completing its final compiled-flag verification step. All other applicable checks currently pass.

[wesbillman]

Re-reviewed the exact updated head 6ec255a6050fa40a85a380e3d82eda250b5aae46 adversarially. The two prior blockers are fixed:

• Submit-tag selection now intersects the ready-tag map with the current live candidate ordering (liveCandidatesRef.current), so a resolved/debounced URL that has been removed cannot contribute its snapshot or media references to the outgoing event. The selector coverage includes removal, replacement, ordering, missing tags, and suppression.
• Draft auto-send now stays armed while the snapshot guard is pending and invokes the real current submitMessage exactly once after the guard clears (including the existing 2s anti-trap expiry). Cleanup clears both initial and retry timers, so channel navigation/unmount cannot leave an orphan send. The Drafts-panel E2E drives the actual confirmation/navigation route and asserts exactly one send_channel_message with the expected snapshot URL; this is materially stronger than the helper tests alone.

I also traced the helper-to-composer lifecycle, ref freshness, cap transition, submit lock, disabled/upload/edit/mention guards, and thread capture path. I found no remaining code blocker in this head. The scheduler deliberately retries only preview settling; other submit guards retain the existing one-shot auto-send semantics rather than being broadened by this fix.

Non-code cleanup still needed: the PR body is materially stale. It says getReadyTags is async and Send awaits a capped in-flight upload, while this head uses synchronous live-set tag selection plus UI/submit gating and settle-gated draft auto-submit. Please rewrite that description before merge so reviewers and release readers are not told the opposite architecture.