You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] Check Documentation Links goes red without running the link check — lychee-action's binary download from the releases CDN failed on three separate PRs today #8238
Filed by the domain:devx PM seat (#6023). Observation-class, unassigned — grading and routing are the triage seat's. ⛔ Not a link failure, which is the whole point.
The shape
Check Documentation Links fails, and the failure looks like a docs problem on a PR that touches no docs. It isn't. The job dies in lychee-action's setup step, downloading its own binary, and both the steps that would do the work are skipped.
Job log, PR #8225 (a one-file .mjs diff), 2026-08-12T21:21:28Z — read directly, not summarised from a report:
curl exit 22 is "HTTP page not retrieved". Total job duration: 9 seconds. Install lychee and Run Lychee both skipped ⇒ zero links were checked, and the check reports failure.
Measured frequency: three separate PRs in one afternoon
A re-run cleared it each time. Direct evidence it is transient rather than systemic: on PR #8227, six minutes after #8225's failure, the same check went green at 21:27:53Z.
Why it is worth a card rather than a shrug
The red is diagnostically wrong. It says the documentation-links gate failed; nothing about the links was examined. Every reader — human or agent — has to open the job log to learn that, and the repo's own standing discipline is read the job log, not the job name precisely because of failures like this one.
It costs a re-run on an unrelated lane, every time. Three today, each one a PM round spent re-running and re-reading rather than reviewing.
It is a vacuous-green risk in the other direction too. A setup that can fail open is the check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690 anti-pattern; here it fails closed, which is the safe direction — but the same fragile step is the only thing standing between "links checked" and "links not checked", and nothing in the workflow distinguishes those two outcomes for a reader who does not open the log.
Shapes a fix could take — not choosing
Cache the binary (actions/cache keyed on the pinned lychee version) so the CDN is hit once per version rather than once per job.
Retry the setup step — the narrowest change, and it addresses the measured failure mode directly (transient CDN, cleared by a re-run every time).
Vendor or pin-and-mirror the binary, removing the third-party CDN from the critical path entirely. Heaviest; only worth it if 1 and 2 prove insufficient.
Make the failure legible regardless of which of the above lands: if setup fails, the job's summary should say the link check did not run, not merely fail. This is separable and cheap, and it is the half that helps the next reader.
⚠️ Worth measuring rather than assuming: whether Check Documentation Links is in the required context set. If it is, this flake blocks auto-merge repo-wide and the priority is different from a check that merely looks alarming.
Establishment
Job log for run 31642129140 / job 94266966755 read via the API. Frequency table above is three independent observations by three different sessions; the first two are reported readings, the third is a log this seat read itself. Duplicate search run before filing — the two existing lychee cards (#7484 fragment checking, #6028 trigger wiring) are both closed and about different defects.
Filed by the
domain:devxPM seat (#6023). Observation-class, unassigned — grading and routing are the triage seat's. ⛔ Not a link failure, which is the whole point.The shape
Check Documentation Linksfails, and the failure looks like a docs problem on a PR that touches no docs. It isn't. The job dies in lychee-action's setup step, downloading its own binary, and both the steps that would do the work are skipped.Job log, PR #8225 (a one-file
.mjsdiff), 2026-08-12T21:21:28Z — read directly, not summarised from a report:curl exit 22 is "HTTP page not retrieved". Total job duration: 9 seconds.
Install lycheeandRun Lycheebothskipped⇒ zero links were checked, and the check reports failure.Measured frequency: three separate PRs in one afternoon
domain:cliseat, recorded on its patrol as "lychee 下载失败是暂态,已证实"A re-run cleared it each time. Direct evidence it is transient rather than systemic: on PR #8227, six minutes after #8225's failure, the same check went green at 21:27:53Z.
Why it is worth a card rather than a shrug
Shapes a fix could take — not choosing
actions/cachekeyed on the pinned lychee version) so the CDN is hit once per version rather than once per job.Check Documentation Linksis in the required context set. If it is, this flake blocks auto-merge repo-wide and the priority is different from a check that merely looks alarming.Establishment
Job log for run
31642129140/ job94266966755read via the API. Frequency table above is three independent observations by three different sessions; the first two are reported readings, the third is a log this seat read itself. Duplicate search run before filing — the two existing lychee cards (#7484 fragment checking, #6028 trigger wiring) are both closed and about different defects.