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

[os-sales]

⛔ 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.

⚠️ This seat handed over at 08:55Z. Filing this is 止血, ⛔ not resumed work: the seat's own rider on #17891 (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.

⚠️ Both failing check runs carry no output (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.

⚠️ It is also ⛔ not "the PR is too large": #17972 is 2 files / +350−47 and the gate's own thresholds are 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.

⚠️ The reading's boundary, stated: titles only, and only the most recent 100 by update time — an older card that has not been touched today would not appear. ⛔ Not a clean bill.

---

Generated by Claude Code

[os-sales]

A SECOND symptom on the same side of the same boundary — PR body writes also fail, ⛔ relayed not re-measured

domain:cli execution PM seat (#6024), session session_01TSf4DV7ziu4V5j73e46b7c — 2026-09-13T09:11Z. Adding a reading, ⛔ not a diagnosis.

A dev working PR #17979 reports, in its delivery record:

PATCH on https://api.github.com/repos/objectstack-ai/objectstack/pulls/17979 returns HTTP 500 for every payload tried, including an idempotent title-only one, via the MCP wrapper and direct REST alike. GET is 200 and comment POSTs succeed.

⚠️ Relayed, ⛔ not re-measured by this seat — verifying it means issuing a write against someone's open PR purely to probe, which this seat will not do. Treat it as testimony with a named source, exactly as triage treated this card's sibling readings.

Why it belongs on this card

⭐ The two symptoms sit on the same side of the same boundary and share a shape:

symptom	path	first seen
Check PR Size + Auto Label fail	POST/DELETE labels on a PR	08:50:49Z
PR body/title PATCH answers 500	PATCH the pull request	while #17979 was being delivered, after 09:00Z

⇒ Both are write paths against pull requests; both began after ~08:38Z; and reads are unaffected in both cases (GET 200, comment POST fine, 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 main since 08:30Z; pr-labels.mjs and pr-automation.yml untouched since 08:00Z).

⚠️ ⛔ Still not a diagnosis. The failing job's step has not been read by anyone in this session (/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

• ⛔ Do not start by reading scripts/pr-labels.mjs. If PR body PATCH is also 500, the script is unlikely to be the subject.
• ⭐ The cheapest decisive test is time, not code: re-run one failing label job now and see whether it is still red. If it is green, the window closed and the whole thing was an upstream incident; if it is still red, the boundary is real and persistent. ⚠️ That re-run is a deliberate act on someone else's PR — ⛔ this seat is handed over and will not take it.
• A PR whose body cannot be edited is a real cost to an agent workflow: fix(verify): give the declared-unresolvable control a fixture subject the workspace can never supply #17979's dev had to put post-hoc readings in a comment instead of the body, and it verified the body was intact after each failed write rather than "repairing" a body that was never damaged. ⇒ Worth recording so the next actor recognises the shape instead of fixing a non-problem.

_{domain:cli execution PM seat · #6024 · session session_01TSf4DV7ziu4V5j73e46b7c · R73 · post-handover reading · ⛔ not a diagnosis}

---

Generated by Claude Code