Context
src/review/visual/actions-fallback.ts's fetchFallbackArtifactShots (line 378) fetches only GET /repos/{o}/{r}/actions/runs/{runId}/artifacts?per_page=100 (page 1) and does .find() for FALLBACK_ARTIFACT_NAME.
Its sibling module src/review/visual/preview-url.ts explicitly documents this exact failure mode ("a single per_page=100 read silently truncates... indistinguishable from an empty one") and was hardened with a bounded pagination walker across four separate endpoints (#7779, #7805, #7469). fetchFallbackArtifactShots — added later, in the same visual-capture epic (#4112) — never got the same treatment.
If the dispatched fallback workflow ever attaches more than 100 artifacts to one run (extra diagnostic/log artifacts, a future workflow change), the target artifact silently falls off page 1 and the function returns [] exactly as if no artifact existed.
⚠️ Required pattern — read preview-url.ts's bounded pagination walker (the fix from #7779/#7805/#7469) before starting. Reuse the same pagination approach for fetchFallbackArtifactShots's artifacts-list read — do not invent a second pagination mechanism.
Requirements
fetchFallbackArtifactShots must page through the full artifacts list (bounded, mirroring preview-url.ts's existing walker) instead of reading only page 1.
- No behavior change when a run has ≤100 artifacts.
Deliverables
Test Coverage Requirements
src/** — 99%+ Codecov patch target, both branches. Add a test with a mocked multi-page artifacts response (target artifact on page 2+) asserting it's still found, plus the existing single-page case continuing to pass.
Expected Outcome
The visual-capture fallback path finds its target artifact regardless of how many artifacts a run has attached, matching the hardening preview-url.ts already has.
Links & Resources
Context
src/review/visual/actions-fallback.ts'sfetchFallbackArtifactShots(line 378) fetches onlyGET /repos/{o}/{r}/actions/runs/{runId}/artifacts?per_page=100(page 1) and does.find()forFALLBACK_ARTIFACT_NAME.Its sibling module
src/review/visual/preview-url.tsexplicitly documents this exact failure mode ("a singleper_page=100read silently truncates... indistinguishable from an empty one") and was hardened with a bounded pagination walker across four separate endpoints (#7779, #7805, #7469).fetchFallbackArtifactShots— added later, in the same visual-capture epic (#4112) — never got the same treatment.If the dispatched fallback workflow ever attaches more than 100 artifacts to one run (extra diagnostic/log artifacts, a future workflow change), the target artifact silently falls off page 1 and the function returns
[]exactly as if no artifact existed.Requirements
fetchFallbackArtifactShotsmust page through the full artifacts list (bounded, mirroringpreview-url.ts's existing walker) instead of reading only page 1.Deliverables
fetchFallbackArtifactShotsfinds the target artifact regardless of how many artifacts are attached to the run (within the same boundpreview-url.tsuses).Test Coverage Requirements
src/**— 99%+ Codecov patch target, both branches. Add a test with a mocked multi-page artifacts response (target artifact on page 2+) asserting it's still found, plus the existing single-page case continuing to pass.Expected Outcome
The visual-capture fallback path finds its target artifact regardless of how many artifacts a run has attached, matching the hardening
preview-url.tsalready has.Links & Resources
src/review/visual/actions-fallback.ts(line 378,fetchFallbackArtifactShots)src/review/visual/preview-url.ts(the pagination walker to reuse, findPreviewUrlFromChecks doesn't paginate check-runs, unlike its sibling functions in the same file #7779/getLatestDeploymentStatus doesn't paginate deployments/statuses reads, unlike its siblings in the same file #7805/fix(review): paginate preview-url.ts's PR-comment and check-run GitHub reads #7469)