From 66ef3f78d108b9d64f1dce640153155fcf88e950 Mon Sep 17 00:00:00 2001 From: claude Date: Wed, 9 Sep 2026 16:04:22 +0000 Subject: [PATCH] Say which runs reasserted the label, because it was not the schedule The docstring credited the every-15-minutes cron with putting Status/Blocked back after a hand-removal. It cannot have: schedule and `issues` events run the workflow from the default branch, weblib-archive's default branch is `main`, and `main` still carries a stale pre-org-label-migration copy at tools/sync_blocked_label.py. That copy looks the label up with `repos/{repo}/labels`; both repos now have zero repo-level labels (all 25 are org-level), so it returns None and exits "skipped: no 'Status/Blocked' label in this repo" without writing anything. Measured today: 377 scheduled and 54 `issues` runs, every one a no-op. The reassertions came from pull_request and workflow_dispatch runs on branches cut from `development`, which consume the shared script. The symptom tracks PR activity, not a timer -- which also explains why it looked intermittent. Mechanism and fix are unchanged; only the attribution was wrong, and a wrong cause in a permanent comment is what sends the next reader to the wrong file. Co-authored-by: bit --- sync_blocked_label.py | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/sync_blocked_label.py b/sync_blocked_label.py index aadd4ab..a64e5f7 100755 --- a/sync_blocked_label.py +++ b/sync_blocked_label.py @@ -25,9 +25,21 @@ entry -- it substitutes a zero-value stub (`id: 0`, every other field blank or null, including `state: ""`), so `d.get("state") != "closed"` used to treat it as "open forever". That kept a cross-repo `Status/Blocked` from ever being removed (weblib-ci#11) and, worse, made the reconciler *reassert* the label -after a human removed it by hand (weblib-archive#30, 2026-09-09): every 15 -minutes it re-ran the same "not closed" test against the same unreadable stub -and put the label back. Treating "cannot tell" as its own outcome -- change +after a human removed it by hand (weblib-archive#30, 2026-09-09): it re-ran the +same "not closed" test against the same unreadable stub and put the label back. + +Which runs did that is worth stating precisely, because the obvious answer is +wrong. It was **not** the every-15-minutes schedule. Scheduled and `issues` +events run the workflow from the *default* branch, and weblib-archive's default +branch is `main`, which still carries a stale pre-org-label-migration local copy +at `tools/sync_blocked_label.py`. That copy resolves the label with +`repos/{repo}/labels`, both repos now have **zero** repo-level labels (all 25 +are org-level), so it returns None and exits with "skipped: no 'Status/Blocked' +label in this repo" — writing nothing, ever. Measured 2026-09-09: 377 scheduled +plus 54 `issues` runs, all no-ops. The reassertions came from `pull_request` and +`workflow_dispatch` runs on branches cut from `development`, which do consume +this shared script. So the symptom appears on PR activity, not on a timer. +See weblib-archive#70 and cfbypass#35 for the stale copies themselves. Treating "cannot tell" as its own outcome -- change nothing, log the issue number -- fixes both without guessing an answer the token cannot support. See `is_resolved()`.