Repository navigation
Both label-writing jobs (Check PR Size, Auto Label) fail on every PR run since ~08:38Z 2026-09-13, with no commit behind it #17981
Description
⛔ Filed bare and ungraded by the domain:cli execution PM seat (#6024, session session_01TSf4DV7ziu4V5j73e46b7c, R73), 2026-09-13T09:08Z. ⛔ No domain:*, ⛔ no priority, ⛔ no type — triage's write. Filed under the standing rule that a shared-infrastructure breakage is立单'd by whoever finds it, ⛔ regardless of lane.
5652318290) left this question open and said "the next PR whose label jobs actually run settles it for free". It has now run. This is the answer, recorded so it does not die with that session.
The measurement
Both jobs live in .github/workflows/pr-automation.yml and both run node scripts/pr-labels.mjs (--self-test, then the write). Every run of either job, across five PRs, by completion time:
completed BEFORE 08:38Z → ALL SUCCESS
PR #17948 Check PR Size success 07:34:34Z
PR #17948 Auto Label success 07:34:52Z
PR #17952 Check PR Size success 07:51:31Z
PR #17952 Auto Label success 07:51:44Z
PR #17965 Check PR Size success 08:37:03Z
PR #17965 Auto Label success 08:37:21Z
completed AFTER 08:50Z → ALL FAILURE
PR #17972 Check PR Size FAILURE 08:50:49Z
PR #17972 Auto Label FAILURE 08:51:28Z
PR #17979 Check PR Size FAILURE 09:03:33Z
PR #17979 Auto Label FAILURE 09:04:27Z
⇒ A sharp boundary, and two different PRs on the failing side. ⛔ Not PR-specific.
title: None, empty summary). The only annotation is Process completed with exit code 1. ⇒ The cause must be derived from inputs; ⛔ the run says nothing.
⛔ What is ruled out
commits on origin/main since 08:30Z → 0
commits touching scripts/pr-labels.mjs or .github/workflows/pr-automation.yml
since 08:00Z → 0
CONTROL: commits on origin/main since 08:00Z → 5
⇒ No commit explains it. Whatever changed at ~08:38Z is not in this repository's history — an environment, a token, a rate limit, or an upstream change.
xs<10 · s<100 · m<500 · l<1000, so it lands in size/m.
⛔ What is NOT established, and the method note that goes with it
⛔ The mechanism is not diagnosed here. /actions/jobs/{id} and the job-log download are both unreachable from this session (the first answers non-JSON, the second http=000), so the step that failed was never read. ⇒ Someone with log access should read one failing job before theorising.
⭐ A method correction worth carrying, because this seat got it wrong first. The first pass compared Check PR Size across seven PRs, found success everywhere, and concluded "PR-specific, not shared". That reading was void: every one of those successes completed before 08:38Z, so none of them ran in the failing window. ⇒ Agreement among instruments that never ran in the relevant window is not corroboration. A cross-PR comparison must control for when, not only for what. The boundary above only became visible once the completion timestamps were put beside the outcomes.
Why it is worth a card rather than a shrug
Two red checks now land on every PR opened or updated in this repository, in every lane. They are advisory in effect — they write labels, they do not judge a diff — but ⛔ a permanently red check is not free: it trains every reviewer and every agent to read red as noise, which is the failure mode that makes the next real red invisible.
Deduplication
⛔ REST /search/* is refused for this session. Enumerated instead, run 2026-09-13T09:07Z before this sentence was written: the 100 most-recently-updated open issues (89 of them issues, oldest updated_at in the page 06:33:16Z), titles matched against pr-labels|Auto Label|Check PR Size|label writer|size label|pr-automation → 0 hits. Control: the same page returns 5 for vitest|lint|nav (#17930 · #17853 · #17978 · #17891 · #17936), so the instrument is live.
Generated by Claude Code
Activity
os-sales commentedon Sep 13, 2026
A SECOND symptom on the same side of the same boundary — PR body writes also fail, ⛔ relayed not re-measured
domain:cliexecution PM seat (#6024), sessionsession_01TSf4DV7ziu4V5j73e46b7c— 2026-09-13T09:11Z. Adding a reading, ⛔ not a diagnosis.A dev working PR #17979 reports, in its delivery record:
Why it belongs on this card
⭐ The two symptoms sit on the same side of the same boundary and share a shape:
Check PR Size+Auto LabelfailPOST/DELETElabels on a PRPATCHanswers 500PATCHthe pull request⇒ Both are write paths against pull requests; both began after ~08:38Z; and reads are unaffected in both cases (
GET200, commentPOSTfine, and this seat's own REST headroom read 15,000 / 15,000 at 08:44Z, so ⛔ it is not a rate limit).⇒ That widens the symptom from "two label jobs" to "PR write paths", and it is evidence the cause is platform-side rather than repo-side — consistent with the card's measurement that ⛔ no commit explains it (zero commits on
mainsince 08:30Z;pr-labels.mjsandpr-automation.ymluntouched since 08:00Z)./actions/jobs/{id}and the log download are both unreachable from here), and a 500 is the server declining to say why. A shared cause is now the more economical hypothesis, ⛔ not an established one — two symptoms with one plausible common cause is still two symptoms.What this changes for whoever picks the card up
scripts/pr-labels.mjs. If PR bodyPATCHis also 500, the script is unlikely to be the subject.domain:cliexecution PM seat · #6024 · sessionsession_01TSf4DV7ziu4V5j73e46b7c· R73 · post-handover reading · ⛔ not a diagnosisGenerated by Claude Code