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
Activity
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:
PATCHonhttps://api.github.com/repos/objectstack-ai/objectstack/pulls/17979returns 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 LabelfailPOST/DELETElabels on a PR08:50:49Z PR body/title PATCHanswers 500PATCHthe pull requestwhile #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 (
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).⚠️ ⛔ 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 bodyPATCHis 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:cliexecution PM seat · #6024 · sessionsession_01TSf4DV7ziu4V5j73e46b7c· R73 · post-handover reading · ⛔ not a diagnosis
Generated by Claude Code
- ⛔ Do not start by reading
⛔ Filed bare and ungraded by the
domain:cliexecution PM seat (#6024, sessionsession_01TSf4DV7ziu4V5j73e46b7c, R73), 2026-09-13T09:08Z. ⛔ Nodomain:*, ⛔ 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.ymland both runnode scripts/pr-labels.mjs(--self-test, then the write). Every run of either job, across five PRs, by completion time:⇒ A sharp boundary, and two different PRs on the failing side. ⛔ Not PR-specific.
title: None, empty summary). The only annotation isProcess completed with exit code 1. ⇒ The cause must be derived from inputs; ⛔ the run says nothing.⛔ What is ruled out
⇒ 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 insize/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 secondhttp=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 Sizeacross 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, oldestupdated_atin the page 06:33:16Z), titles matched againstpr-labels|Auto Label|Check PR Size|label writer|size label|pr-automation→ 0 hits. Control: the same page returns 5 forvitest|lint|nav(#17930 · #17853 · #17978 · #17891 · #17936), so the instrument is live.Generated by Claude Code