fix(github): show private-repo body images from signed links - #3252

Problem

In the GitHub panel, images and videos in a private repository's PR or issue body show as "Image unavailable".

The panel loads each one from its markdown link, https://github.com/user-attachments/assets/<id>. For a private repository, that link needs a signed-in GitHub browser session. Buzz has none, so GitHub returns 404. Public repositories are not affected.

The rendered body HTML that the panel already reads (body_html / bodyHTML) has a signed link for each asset on private-user-images.githubusercontent.com. Signed links load without a sign-in, but they expire after about 5 minutes and change on every read. Each reader gets them from their own gh sign-in, so only people who can read the repository see the media. Nothing goes through the relay.

Fix

Media loads its own markdown link first, exactly as on main. The signed link is used only when that fails.

• attachments.ts: attachmentMetadata() also keeps each asset's signed link, under the same asset key. A new signedUrl() looks it up. attachmentFor() still returns the markdown link.

• GitHubBody.tsx, per media element:

  1. The own link loads: nothing else happens. Public repositories make no extra request or read.
  2. The own link fails and the asset has a signed link: that element switches to it. No GitHub read.
  3. The signed link fails (for example, it expired): the body asks the panel to read again. One read runs at a time. A source that failed and has not loaded since does not read again, so a broken asset cannot loop. When the new body arrives, only failed elements take their new signed link. Working media keeps its element and link, so nothing reloads or restarts on polls.
  4. No signed link: it shows the original link on failure, as on main.

  The markdown components object moved to module scope (with a small context for the media renderer), so a new read no longer remounts every media element.

• index.tsx: passes the panel's existing load to GitHubBody as refresh. No new fetch code. A failed reload of an issue panel now keeps the issue that is shown, the same as pull request panels. A failed first load still shows the error.

The app's CSP already allows private-user-images.githubusercontent.com (media-src) and https: images (img-src). No config change.

Screenshots

Explanatory guide; unmodified screenshots below. Captured from the real GitHubPanel (opened by clicking a PR link in a message) with Playwright, under the packaged img-src/media-src policy. GitHub responses are mocked: each asset's own link returns 404, as for a private repository, and its signed link returns 200. All data is fictional. 1440×950 CSS px viewport, 2x. Chromium shown; WebKit passed the same assertions.

Before — main at 7f35bb1	After — this PR at f4de506

Light theme, wide panel, larger text, keyboard

Before, light	After, light

Wide panel (774 px). Media keeps the shared MediaAttachment maximum sizes.

Root text at 20px. The title wraps cleanly; the video is reachable by scrolling the panel.

Top	Scrolled

Keyboard: one Tab from the title reaches "Open image fullscreen" with a visible focus ring. Enter opens the viewer with the signed image; Escape closes it and returns focus to the preview.

Focus on the preview	Viewer open

Tests

• RTL (GitHubBody.test.tsx, attachments.test.ts):

  • own link first for images and videos;

  • own-link failure switches to the signed link with no read;

  • signed-link failure reads once, with the original link as the fallback link;

  • only the failed image takes the renewed link, and the loaded video keeps its DOM node and link;

  • a renewed link that fails before loading does not read again;

  • one read at a time, and a later expiry reads again after a failed read;

  • public and raw media keep their own links;

  • GitHubPanel reads the PR again when its signed image fails;

  • an issue panel stays shown when that read fails;

  • signedUrl() finds private assets and returns nothing for public and raw ones.

  • with fake timers: after a failed renewal, reads again at 30s, at most 3 times; a renewed link that loads stops retrying without refilling them; loads of other media do not refill them; media that loads then fails on each link stays within the cap; unmount clears the timer; no timer for public media or media whose own link loads; a link a poll delivers is tried before reading again; a network failure (code 2) on a signed video neither reads again nor remounts the player, and shows the original link until the video loads again; loaded audio that fails on a network error shows its original link (both fail on 2220d8e, pass on d057182).

  Run against the previous signed-first head, 9 of these fail; all pass on this change. The retry tests fail on f4de506 (no retry) and pass on db501c7.

• Browser journey, 1 added, 0 removed (tests/browser/github-body.spec.mjs, "private repository media › private PR media falls back to its signed links under the packaged media policy"). jsdom loads no media and enforces no CSP, so only a real engine can show that a real 404 on <img> and <video> triggers the switch, and that the signed link decodes under the packaged policy. It reuses the existing spec's fixtures. The deliberate 404s use the fixture's existing expectedStartupLoadFailure option, scoped to this case.

  • Fails on main in Chromium and WebKit (the image becomes "Image unavailable").
  • Passes on this change in both. The existing journey also passes unchanged in both.

• bin/pnpm exec vitest run src/bundled/github: 22 files, 374 passed. tsc --noEmit and biome check --error-on-warnings pass. bin/pnpm test:browser tests/browser/github-body.spec.mjs --project chromium --project webkit: 4 passed.

• Hooks: committed and pushed through lhm with lefthook 2.2.2. Pre-commit (literal names, icons, biome, sadscan) and pre-push (types and related unit tests, design system) passed.

• Real data: for a private squareup PR read with gh, the asset's own link returns 404 without cookies and its signed link from body_html returns 200 image/png. This is the shape the mocks use.

• Human test (Allen): in a dev build of this branch (bin/just desktop me) signed in as himself, the images in a private squareup PR body load in the GitHub panel; the same PR in the released app shows "Image unavailable". Tested at db501c7; the later commits change only failure handling, and Allen confirmed the test covers 2220d8e.

• Agent app run: skipped by Allen; his test in the native app covers it. The browser journey exercises the fallback in Chromium and WebKit.

Review

• Round 1 (3 findings): fixed.
• After a renewal read failed, failed media stayed on its original link until it loaded, so an issue panel (which does not poll) stayed broken until reopened. Fixed in db501c7 at the author's request: media still failed with no newer link reads again after 30 seconds, at most 3 times. One read and one timer at most; a link a poll delivers is tried first; unmount clears the timer.
• BuilderBot on db501c7: a load refilled the retries, and media that loaded then failed read again at once, so a partly loading video could read in a loop. Fixed in 15c823b: each source reads at once only on its first failure and the 3 retries never refill, so a panel reads at most once per signed source plus 3 times.
• BuilderBot on 15c823b: a network blip on a signed video renewed its link and remounted the player, which aborted the player's own quiet reload. Fixed in 2220d8e: a media network error (code 2) is left to the player. An expired or missing link fails as code 4, checked in Playwright Chromium and WebKit against 403 and 404 responses, so it still takes another link.
• Kyle (review on 2220d8e): the code-2 bypass also skipped audio, which has no quiet reload, and a loaded video kept hiding its original link after its reloads gave up. Fixed in d057182: only video skips a network error, and it shows the original link until it loads again. BuilderBot on d057182: no findings.
• Declined by the author (Allen), from BuilderBot on 2220d8e: after a long network outage exhausts the player's own reloads, a signed video stays "Video unavailable" until the panel is reopened. All Buzz videos behave this way; a fix needs a shared player change.
• Declined by the author (Allen): a renewal remount closes an open full-screen viewer. It needs the viewer's own load to fail on a link over 5 minutes old; clicking the image again opens it with the new link.
• Declined by the author (Allen): signed-link pairing does not cover user-attachments/files. Those are downloads, not inline media. Legacy user-images links are already paired by the CDN path.

Limits

• A failed asset that never loads (for example, deleted) costs at most 1 read plus 3 retries 30s apart per panel. On a PR panel it also takes each newer signed link that polling brings: one image request per 30s poll, with no extra GitHub API reads.

buzz-review-completed

🤖 Generated with Claude Code