The design principle in the workflow header is that everything which can fail
runs after the comment, so a red run always carries its explanation. Both
carriers have size limits, and one realistic change crosses them together.
A terminology or formatting sweep over all 20 English pages in a nine-locale
repo produces 180 stale entries.
translation-status --format markdown --diff renders a collapsed diff per
entry. Rewriting a 15 KB page yields roughly 30 KB of diff, so the report
reaches several megabytes. GITHUB_STEP_SUMMARY is capped at 1 MiB per step;
GitHub drops an oversized summary and annotates the run. The step stays
green, so nothing about the failure points at it.translation-status --comment sees the body cross its 60000-character
ceiling, strips the diffs, and appends "See the workflow run's job summary
for the complete report" — pointing at the summary that step 1 just lost.
So at exactly the size where the report is least reconstructible by hand, the
comment lists 180 page names without saying what changed and points at an empty
summary. On a push-to-main run there is no comment at all, so the summary is
the only channel and it is the one dropped.
The two limits are independent, which is why neither side noticed: the comment
fallback in halos-org/docs-tools#2
is about the comment, and nothing bounds the summary.
Options: write the no-diff report to the summary when the diff report exceeds
roughly 900 KB and say so in the appended text, or upload the full report as a
run artifact and point the comment's fallback at that instead.
Found by the adversarial reviewer on
#39. Not reproduced —
the probe was two pages in one locale, far below either limit.
The design principle in the workflow header is that everything which can fail
runs after the comment, so a red run always carries its explanation. Both
carriers have size limits, and one realistic change crosses them together.
A terminology or formatting sweep over all 20 English pages in a nine-locale
repo produces 180 stale entries.
translation-status --format markdown --diffrenders a collapsed diff perentry. Rewriting a 15 KB page yields roughly 30 KB of diff, so the report
reaches several megabytes.
GITHUB_STEP_SUMMARYis capped at 1 MiB per step;GitHub drops an oversized summary and annotates the run. The step stays
green, so nothing about the failure points at it.
translation-status --commentsees the body cross its 60000-characterceiling, strips the diffs, and appends "See the workflow run's job summary
for the complete report" — pointing at the summary that step 1 just lost.
So at exactly the size where the report is least reconstructible by hand, the
comment lists 180 page names without saying what changed and points at an empty
summary. On a
push-to-main run there is no comment at all, so the summary isthe only channel and it is the one dropped.
The two limits are independent, which is why neither side noticed: the comment
fallback in halos-org/docs-tools#2
is about the comment, and nothing bounds the summary.
Options: write the no-diff report to the summary when the diff report exceeds
roughly 900 KB and say so in the appended text, or upload the full report as a
run artifact and point the comment's fallback at that instead.
Found by the adversarial reviewer on
#39. Not reproduced —
the probe was two pages in one locale, far below either limit.