Summary
Two bugs observed live in the "Visual preview" PR comment table on a real repo review:
-
Mobile screenshots are oversized/undownscaled. capturePage's display-thumbnail generation
(src/review/visual/capture.ts) is gated to viewportName === "desktop" only. The mobile capture
is 390px wide — already under the display-downscale width cap — but shot.ts captures
fullPage: true, so a mobile screenshot's HEIGHT is just as unbounded as desktop's. The result: a
several-thousand-pixel-tall full-page mobile capture renders at native size in the comment table
instead of a bounded thumbnail. Separately, downscaleForDisplay
(src/selfhost/stubs/image-downscale.ts) only bounds width (no fit/height), so even removing the
desktop-only gate alone would not have fixed this for a narrow-but-tall image.
-
The "after" cell never resolves out of the loading placeholder for a repo with no discoverable
preview-build signal. buildCapture's preview-build-state check
(src/review/visual/capture.ts) only applies the poll-budget give-up logic
(preview-poll-budget.ts, MAX_PREVIEW_POLL_ATTEMPTS) when getPreviewBuildState returns
"building" or "succeeded". When it returns "absent" (no Workers-Builds-named check-run found
at all — the case for a repo whose frontend has no preview-deploy CI configured), nothing happens:
previewPending/previewFailed both stay false, so the "Rendering preview…" spinner placeholder
is shown and never re-evaluated to a terminal state on any subsequent review pass.
Expected behavior
- The mobile row's thumbnail is bounded on both width and height, matching the desktop row's existing
behavior.
- When no preview-build signal is ever found (and
actions_fallback isn't configured to fill the
gap), the "after" cell eventually shows the honest "Preview deploy failed — review manually" card
after a bounded number of poll attempts, instead of spinning forever.
Validation
npm run test:coverage (unsharded) on the affected files, both new/updated branches covered.
npm run test:ci full local gate green.
Summary
Two bugs observed live in the "Visual preview" PR comment table on a real repo review:
Mobile screenshots are oversized/undownscaled.
capturePage's display-thumbnail generation(
src/review/visual/capture.ts) is gated toviewportName === "desktop"only. The mobile captureis 390px wide — already under the display-downscale width cap — but
shot.tscapturesfullPage: true, so a mobile screenshot's HEIGHT is just as unbounded as desktop's. The result: aseveral-thousand-pixel-tall full-page mobile capture renders at native size in the comment table
instead of a bounded thumbnail. Separately,
downscaleForDisplay(
src/selfhost/stubs/image-downscale.ts) only bounds width (nofit/height), so even removing thedesktop-only gate alone would not have fixed this for a narrow-but-tall image.
The "after" cell never resolves out of the loading placeholder for a repo with no discoverable
preview-build signal.
buildCapture's preview-build-state check(
src/review/visual/capture.ts) only applies the poll-budget give-up logic(
preview-poll-budget.ts,MAX_PREVIEW_POLL_ATTEMPTS) whengetPreviewBuildStatereturns"building"or"succeeded". When it returns"absent"(no Workers-Builds-named check-run foundat all — the case for a repo whose frontend has no preview-deploy CI configured), nothing happens:
previewPending/previewFailedboth stayfalse, so the "Rendering preview…" spinner placeholderis shown and never re-evaluated to a terminal state on any subsequent review pass.
Expected behavior
behavior.
actions_fallbackisn't configured to fill thegap), the "after" cell eventually shows the honest "Preview deploy failed — review manually" card
after a bounded number of poll attempts, instead of spinning forever.
Validation
npm run test:coverage(unsharded) on the affected files, both new/updated branches covered.npm run test:cifull local gate green.