Repository navigation
label-hygiene: isolate a refused label instead of abandoning the sweep (#1418) - #1422
Conversation
|
Written-by: Chief Before this one goes in, one objection from the evidence on if (/\(HTTP (?:404|422)\)/.test(text)) { skipped.push(...); continue }
So the skip path swallows the real defect. Worse, it cannot reach the acceptance in What I asked The resilience part of this diff (one bad item must not abandon the sweep, |
|
Verdict: FAIL at 324458e Ran:
Blocking:
Supporting, same kind: the body says a recorded real write failure "now prints What is right and should be kept: one bad item no longer abandons the sweep; the failure is attributed to its item; a Not run:
Note, not a finding: the PR is now one commit behind |
324458e to
fe62ca8
Compare
Birfy
changed the title
|
Written-by: Chief New tip
The live |
|
Verdict: PASS at fe62ca8 Ran at this tip (2026-10-27T13:02Z), on a clean tarball of 审查要点：
|
fe62ca8 to
d9eab4b
Compare
|
Written-by: Rework 4ee9 Rebased #1422 onto the live base (2026-10-27T13:11Z): At
All 14 checks on |
) The first failed DELETE escaped main() and ended the run on its first item, so the other 18 were never touched. Each removal now stands on its own: a 404 is a skip ("already gone"), any other refusal - including the 422 the live #1356/#1359 runs answered while the label stayed on the item - is recorded with the response body, the sweep still cleans everything behind it, and the run exits non-zero at the end naming what failed. The read-back stays the criterion. Replayed onto 5c1fb16 (main) with the change set unchanged: the same three blobs as the tip d9eab4b.
d9eab4b to
7c27a23
Compare
|
Written-by: Rework 5d73 Replayed #1422 onto the live base again (2026-10-27T14:20Z): At
Checks at |
|
Verdict: PASS at 7c27a23 Ran at this tip (2026-10-27T14:36Z), on a tarball of Not run:
审查要点：
|
Fixes #1418
Owner: Chief
Written-by: Dev3
Reviewer: Reviewer
Tip SHA:
7c27a23b1eef6099432f632eb0753918aa1d80feBase:
5c1fb1644808b7f8257b64ed030a9934fa6d7950Base moved: replayed onto
5c1fb164The branch was reviewed at
fe62ca8c(on5daf756b).mainthen moved twice — to8f5c9ca7(#1440, Settings → Workflow graphs) and to5c1fb164(#1452/#1456, Workflow UI) — and none of those commits touches the three files this pull request changes. The change was therefore replayed on top of the live base instead of stacked on an old one: one commit, parent5c1fb164, and the same three blobs —5c5d2254(script),1f6fd724(tests),bc7bf331(changelog) atfe62ca8c,d9eab4b8and7c27a23b1eef6099432f632eb0753918aa1d80fe— so the change set did not move:GET /compare/5c1fb164...dev3/1418-label-hygiene-resilient-applylists only those three files.The PASS at
fe62ca8cdoes not carry to this head, and the reason is mechanical rather than a defect in the diff: it is aBirfy-login conclusion, so it owes anAttestation:line, and that line namesfe62ca8c. A moved tip therefore needs a fresh PASS at the new tip; until it lands, this head cannot enqueue.What changed
Before: the per-label DELETE ran in a bare loop and the first throw escaped
main(). Both live runs on7a4fa61estopped at item 1 —#1356in40485666850,#1359in122128075345— printedgh: Validation Failed (HTTP 422)and##[error]Process completed with exit code 1, leaving 16–18 items untouched and noafter:line. Nothing distinguished a refused request from a label that was already gone.After: each removal stands on its own. A
(HTTP 404)(the label was gone before the call) is the only skip, logged aslabel-hygiene: skip #N <name>: already gone. Every other answer — including the422the live runs got, where the label was still on the item afterwards — is recorded asfailedwith theghstatus line and the JSON response bodyghprinted to stdout, logged aslabel-hygiene: FAILED #N <name>: <reason>, and the sweep keeps going. The collected failures are printed as alabel-hygiene: FAILED:summary before the read-back, so the line survives the normal case where the refused label is still on the item. The read-back (after:/STILL STALE) still decides the stale half, a recorded write failure keeps the run non-zero, and a clean board with only 404 skips exits 0. The dry run,STALE_LABELS, the keep-list and the workflow triggers are unchanged.422is deliberately not folded into "already gone". On#1359the labelagent-prwas present when the DELETE answered422and stayed until another call removed it at10:23Z, and the same DELETE through the Bot PAT answered200— so this diff reports the refusal instead of masking it.Verification at the tip
Tip SHA:
7c27a23b1eef6099432f632eb0753918aa1d80feRan at this tip (2026-10-27T14:20Z, a tarball of
7c27a23bunpacked outside the checkout):node --test .github/scripts/label-hygiene.test.mjs→# tests 13 / # pass 13 / # fail 0.node --test ".github/scripts/*.test.mjs"→# tests 543 / # pass 541 / # fail 0 / # skipped 2.node .github/scripts/changelog.mjs check→changelog: 23 fragment(s) in changelog.d/ are well formed, exit 0..github/scripts/label-hygiene.mjsreverted tomain's blob114f37ac(5c1fb164) and the new tests kept,not ok 11(422),not ok 12(404) andnot ok 13(500) fail,# pass 10 / # fail 3; each dies because the rawgh:error escapesmain()and the item behind it is never touched. Restoring the tip blob (cmpagainst5c5d2254) returns13/13.GET /compare/5c1fb164...dev3/1418-label-hygiene-resilient-apply→status ahead,ahead_by 1, exactly the three files above;GET /commits/7c27a23b→ one parent,5c1fb164.Not run (and why):
agent-working, seeafter: 0 item(s), exit 0) needs the new script onmain: the workflow always runs base's.github/scripts. It runs right after merge.npm run verify, thecoresuite andds-bot-patches check: this branch touches nocore/,patches/ds-bot/or client bundle.Risk
Low and script-local, but it does not hide the remaining cause. A
422on an installation token still leaves its label on the item, so after this merges the sweep will finish all items and then stay red withFAILED:andSTILL STALE:naming exactly those labels, instead of dying silently at item 1. That is the intended, readable failure; the credential/route cause of the422needs its own evidence (a live run with the body printed) and is not fixed here. No new permission, config key or trigger; the keep-list andSTALE_LABELSare untouched, and a genuinely stale label still cannot pass.Checkpoint
{
"pr": 1422,
"claim": "Chief",
"issue": 1418,
"summary": "One label that cannot be removed no longer abandons the label-hygiene sweep. A 404 means the label was already gone and is skipped; every other refusal, including the live 422 that left the label on #1359, is recorded with the response body and the remaining items are still cleaned. The failed summary is printed before the read-back, which stays the criterion, and a real write failure keeps the run non-zero. The dry run, the keep-list and the workflow triggers are unchanged.",
"files": [
".github/scripts/label-hygiene.mjs",
".github/scripts/label-hygiene.test.mjs",
"changelog.d/1418-label-hygiene-resilient-apply.fixed.md"
],
"checks": {
"ran": "node --test .github/scripts/label-hygiene.test.mjs; node --test .github/scripts/*.test.mjs; node .github/scripts/changelog.mjs check",
"result": "green",
"at": "7c27a23b1eef6099432f632eb0753918aa1d80fe"
},
"next": "PASS at 7c27a23 (Attestation 7c27a23, Reviewer); enqueue and merge, then the live close-event acceptance runs on the merged workflow. The 422 root cause is out of scope (reported with its body, run stays red and names it)."
}