Found by the adversarial reviewer on hatlabs/halpi2#49, reproduced here.
The step order in translation-status.yml exists so that "a red run always carries the explanation of why" — the workflow header says so. It delivers that for stale translations and for nothing else.
The comment step runs at line 89. Build the site is at 125 and Check anchors at 128, so a --strict build error and a broken anchor both fail the run after the comment is already posted, saying translations are current. And translation-status --comment renders from render_markdown(entries, None), which never computes the unclassified_pages case that --check exits 2 on — so even the translation half of the verdict can disagree with the comment.
Reproduced on a real repo. Dropping a stray docs/stray-probe.md into hatlabs/halpi2:
uv run translation-status --comment → **da** — 20 current (all nine locales)
uv run translation-status --check → exit 2
The author sees a red required-looking check under a bot comment telling them everything is fine, and the actual reason is in the job log — which is the place this step order was built to avoid sending people.
Fix directions, either or both:
The anchor and build failures need the workflow-side fix regardless: the checker cannot report on a build that has not run yet.
Found by the adversarial reviewer on hatlabs/halpi2#49, reproduced here.
The step order in
translation-status.ymlexists so that "a red run always carries the explanation of why" — the workflow header says so. It delivers that for stale translations and for nothing else.The comment step runs at line 89.
Build the siteis at 125 andCheck anchorsat 128, so a--strictbuild error and a broken anchor both fail the run after the comment is already posted, saying translations are current. Andtranslation-status --commentrenders fromrender_markdown(entries, None), which never computes theunclassified_pagescase that--checkexits 2 on — so even the translation half of the verdict can disagree with the comment.Reproduced on a real repo. Dropping a stray
docs/stray-probe.mdintohatlabs/halpi2:The author sees a red required-looking check under a bot comment telling them everything is fine, and the actual reason is in the job log — which is the place this step order was built to avoid sending people.
Fix directions, either or both:
if: always(), so the body is the verdict rather than a precursor of it. Costs nothing when the run is green.--commentcover what--checkfails on, including the exit-2 unclassified-pages case. That half is in halos-org/docs-tools, next to The PR comment body can exceed GitHub's size limit, and half of it is a false diagnostic docs-tools#2 which already reworksrender_comment.The anchor and build failures need the workflow-side fix regardless: the checker cannot report on a build that has not run yet.