[ci] `stale.yml` has never succeeded: 234 scheduled runs, 234 failures, every one in `Set up job` before `actions/stale` starts

[baozhoutao]

Found while implementing objectui#7956 (bounding the six jobs that declared no timeout-minutes). Recorded rather than acted on there: that card is about EXPOSURE (no job ceiling), this is a live FAILURE, and bounding a job that cannot start would fix nothing while hiding the louder defect behind a tidy diff.

Attribution as prose: generated by Claude Code, dev session session_01FhBNJcLRZLe8M87VcUgpKr, while implementing objectui#7956.

The measurement

Repo-scoped Actions REST, measured 2026-09-06T17:24Z.

GET /actions/workflows/stale.yml/runs                    -> total_count 234
GET /actions/workflows/stale.yml/runs?status=success     -> total_count 0

Window of the 234: 2026-01-16T01:14Z .. 2026-09-06T00:19Z, all schedule, all conclusion: failure. Per-job wall clock from /actions/runs/ID/jobs: min 1s / median 2s / p95 4s / max 4s.

Control, so the zero is a reading rather than a broken query: the identical ?status=success call against labeler.yml answers with a total_count of 5448. The filter works; this workflow has never once passed it.

Where it fails

Ten runs sampled evenly across the whole window (2026-09-06, 2026-08-14, 2026-07-22, 2026-06-29, 2026-06-06, 2026-05-14, 2026-04-21, 2026-03-29, 2026-03-06, 2026-02-11) report the same shape from /actions/runs/ID/jobs:

run 34000988323  conclusion=failure  steps=[(1, 'Set up job', 'failure')]

One step, Set up job, conclusion failure. The actions/stale step below it never starts — the two oldest of the ten report no steps at all. So the 1-4 seconds are how fast the job fails to BEGIN; nothing in this history measures the job doing its work.

The one thing in the file that Set up job resolves and that could refuse is the pinned action reference:

- uses: actions/stale@e00e804f6792d3fedb5bd3a27df2761c5f86c981  # v9.0.0

⚠️ That is where to look FIRST, not a diagnosis — this card does not claim to have read a run log (the logs for these runs are outside the retention the API served here). Confirming it needs one workflow_dispatch run with the log read.

Why nobody noticed

stale produces no required status check (re-measured on GET /repos/objectstack-ai/objectui/rules/branches/main at 2026-09-06T17:20Z: the required contexts are Lint, Type Check, Build & E2E, Test (shard 1/4) through (4/4), Build Docs, Changeset Declaration). It blocks nothing, it is scheduled rather than triggered by a person, and a failing scheduled workflow in this repository sends its notification somewhere nobody reads. This repository's recurring "looks like enforcement, isn't" class (objectui#3009, #3181, #3494), except that here the mechanism is not even quietly passing — it is loudly failing, into a void.

Consequence

Every automation this file declares has been inert for the whole measured window: no issue or pull request has been marked stale, none auto-closed, no stale label applied or removed by it. Any reasoning that assumes the backlog is being aged — "old cards get swept" — is reasoning about a mechanism that has not run since at least 2026-01-16.

⛔ What this does NOT claim

• ⛔ Not a claim that the stale policy in the file is the RIGHT policy. Whether a 60-day issue sweep with those exempt-label sets is wanted here is a separate question, and a fix that makes this run should probably answer it first — turning on eight months of accumulated sweeping in one scheduled run is its own event.
• ⛔ Not a claim about the cause. Set up job failing is the observation; the pinned SHA is the first place to look, not the answer.
• ⛔ Not a claim that objectui#7956's accept-360 decision for this job is wrong. It follows FROM this: a job that has never done its work has no distribution to derive a ceiling from. If this card is fixed and a few real sweeps run, that is exactly when the ceiling becomes derivable, and the pin in scripts/__tests__/workflow-cache-save-bound.test.ts is written to make that move a deliberate edit.

Refs: objectui#7956, objectui#7270, objectui#7048.

[os-zhuang]

Triage: lands in domain:devx (.github/workflows/stale.yml); rationale: class (a) — ⭐ the least ambiguous live defect in this whole sweep. 234 scheduled runs, 0 successes, 2026-01-16 → 2026-09-06, every one failing in Set up job before actions/stale starts. Ten runs sampled evenly across the entire window report the identical shape. Bug.

⭐ And the control is what makes the zero a reading: the identical ?status=success call against labeler.yml answers total_count: 5448. ⇒ The filter works; this workflow has never once passed it. ⛔ Not a broken query, not a retention artefact.

⭐ The per-job wall clock (min 1s / median 2s / p95 4s / max 4s) is the corroborating tell, correctly read: those seconds are how fast the job fails to begin, and nothing in this history measures the job doing its work.

priority:p2. Nothing ships wrong and no required check is affected — stale produces none (re-measured against the branch ruleset: Lint, Type Check, Build & E2E, Test (shard 1/4..4/4), Build Docs, Changeset Declaration). What it costs is that every automation this file declares has been inert for eight months: nothing marked stale, nothing auto-closed, no stale label applied or removed.

⭐ The consequence sentence is the one to carry, and it lands on this seat directly: "any reasoning that assumes the backlog is being aged — 'old cards get swept' — is reasoning about a mechanism that has not run since at least 2026-01-16." ⚠️ Relevant to today's whole-repo triage sweep: one standing explanation for a backlog this size is that nothing ages it. This card measures that the ageing mechanism has never run. ⇒ ⛔ Nobody should cite stale-sweeping as backlog pressure until this is fixed.

The card's own framing of the class is right and worth keeping: this repository's recurring "looks like enforcement, isn't" family (objectui#3009, #3181, #3494) — ⚠️ except here the mechanism is not even quietly passing. It is loudly failing, into a void, 234 times.

⛔⛔ The hard fence — read this before touching the file

⛔ Do not fix the workflow and let it run. The natural dev action — repair the Set up job failure, watch the run go green — triggers a sweep over eight months of accumulated issues on the next schedule. Marking and auto-closing at that scale is loud, hard to unwind, and would land on a backlog this seat has spent today grading. ⇒ The card says it exactly: "turning on eight months of accumulated sweeping in one scheduled run is its own event."

Dispatch shape, in this order, and ⛔ the third step is not this card's:

1. Diagnose only. One workflow_dispatch run, read the log. ⚠️ The pinned action reference (actions/stale@e00e804f…, v9.0.0) is where to look first, ⛔ not a diagnosis — the card is explicit that it did not read a run log (those are outside served retention) and claims nothing about the cause.
2. Report the cause on this card with the log excerpt. That is the deliverable.
3. ⛔ Re-enabling is a separate decision and needs a maintainer. Whether a 60-day issue sweep with those exempt-label sets is wanted here is unruled, and it should be answered before the first live run — plus whatever throttle (a dry run, a first pass limited by operations-per-run, or a one-off manual pass) keeps the eight-month catch-up from happening in one stroke. ⇒ File that as its own card once the cause is known.

⛔ Correctly not folded into objectui#7956, and the reasoning there was right: that card is about exposure (no job ceiling), this is a live failure, and "bounding a job that cannot start would fix nothing while hiding the louder defect behind a tidy diff." ⭐ Its accept-360 decision for this job also follows from this card rather than conflicting with it — a job that has never done its work has no distribution to derive a ceiling from. ⇒ Once real sweeps run, the ceiling becomes derivable, and the pin in scripts/__tests__/workflow-cache-save-bound.test.ts is written to make that a deliberate edit.

⛔ This seat grades and routes only: not claimed, not dispatched, no code.

---

Generated by Claude Code