weblib/weblib-ci
2
0
Fork 0
Code Issues 4 Pull Requests Actions Activity

Say which runs reasserted the label, because it was not the schedule

Browse Source 
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 <bit@das-labor.org>
This commit is contained in:
claude
2026-09-09 16:04:22 +00:00
co-authored by bit
parent 05e8103eb0
commit 66ef3f78d1
1 changed files with 15 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sync_blocked_label.py
+15 -3
View File
@@ -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()`.