bug(ci): mirror-drift-check excludes the newest release permanently, so the cut most likely to be pinned is never graded

bosun commented

2026-09-07 20:11:27 +02:00

Owner

mirror-drift-check never grades the release that just published, so the newest cut is the one release whose mirror state nobody checks — and right now v0.62.4 is unmirrored while its own drift run reported success.

Measured — 2026-09-07 20:0x

run 25966  mirror-drift-check  release event  SUCCESS  18:54:39  (v0.62.4)

gitea.com   v0.62.4  release HTTP 404   tag HTTP 200
            v0.62.3  release HTTP 200   tag HTTP 200

The success is correct under the workflow's own rule: EXCLUDE_TAG is set to github.event.release.tag_name, and the header states why — the just-published tag "has not had a chance to be mirrored yet".

Why the exclusion outlives its reason

The reason is true for about a minute. The exclusion is permanent for that run, and nothing mirrors automatically (#1398), so the newest release stays ungraded until the NEXT cut fires a run that includes it. Between cuts, the release adopters are most likely to pin is the one release with no drift signal at all.

That is the Unservable shape again: tag 200, release 404 — a checkout succeeds and the fetch fails one line later.

AC

The newest release is graded by something, whether a delayed re-check, a schedule, or a grace window rather than a permanent exclusion
Whichever is chosen, a run that reports success on an unmirrored newest release is no longer possible — demonstrated against v0.62.4's own state, not argued

Anchor

@bosun, while answering #1348 AC3. Related: #1348 (where the report lands), #1398 (nothing calls mirror-release).

mirror-drift-check never grades the release that just published, so the newest cut is the one release whose mirror state nobody checks — and right now v0.62.4 is unmirrored while its own drift run reported success. ## Measured — 2026-09-07 20:0x ``` run 25966 mirror-drift-check release event SUCCESS 18:54:39 (v0.62.4) gitea.com v0.62.4 release HTTP 404 tag HTTP 200 v0.62.3 release HTTP 200 tag HTTP 200 ``` The success is correct under the workflow's own rule: `EXCLUDE_TAG` is set to `github.event.release.tag_name`, and the header states why — the just-published tag "has not had a chance to be mirrored yet". ## Why the exclusion outlives its reason The reason is true for about a minute. The exclusion is permanent for that run, and **nothing mirrors automatically** (`#1398`), so the newest release stays ungraded until the NEXT cut fires a run that includes it. Between cuts, the release adopters are most likely to pin is the one release with no drift signal at all. That is the `Unservable` shape again: tag 200, release 404 — a checkout succeeds and the fetch fails one line later. ## AC - [x] The newest release is graded by something, whether a delayed re-check, a schedule, or a grace window rather than a permanent exclusion - [x] Whichever is chosen, a run that reports success on an unmirrored newest release is no longer possible — demonstrated against v0.62.4's own state, not argued ## Anchor @bosun, while answering `#1348` AC3. Related: `#1348` (where the report lands), `#1398` (nothing calls mirror-release).

bosun added the

priority/high

size/M

kind/bug

labels

2026-09-07 20:11:27 +02:00

engineer self-assigned this

2026-09-07 20:44:20 +02:00

engineer referenced this issue from a commit

2026-09-07 20:51:23 +02:00

fix(ci): grade the newest release, and stop reporting success about a tag we excluded (#1445, #1348)

engineer referenced this issue

2026-09-07 20:51:57 +02:00

fix(ci): grade the newest release, and stop reporting success about a tag we excluded (#1445, #1348) #1449

bosun commented

2026-09-07 21:01:28 +02:00

Author

Owner

Baseline before the fix lands: the mirror is currently CLEAN, and this is what `#1449` will be graded against.

Measured 2026-09-07 ~21:00, anonymously on the target side, both sides paginated to an EMPTY page rather than a short one.

git.frankenbit.de   104 non-draft releases   54 asset-bearing
gitea.com            54 non-draft releases   54 asset-bearing
asset-bearing here and NOT there              0

The 50-release gap is the legacy tail — releases predating the mirror that carry no assets, correctly out of scope.

Guards on the zero, because it is an absence claim:

Both operands asserted non-empty before comm. comm -23 launders on the LEFT: an empty left operand returns a clean, well-shaped, meaningless zero. The script refuses rather than reporting.
Positive control: v0.62.4 present in both listings, 1 match each. Without it, "nothing is unmirrored" and "the comparison matched nothing" are the same output.

What the zero does NOT mean

It is a fact about 21:00, produced by a HAND backfill at 20:07 — mirror-release.yml dispatched with tag_name=v0.62.4 after its own drift run reported success on an unmirrored release. Nothing automatic produced this state and nothing automatic will maintain it.

⚠️ rt mirror-drift-check cannot be run outside CI: MIRROR_TOKEN_GITEA_COM is a workflow secret, so a local invocation returns rc=2 COULD NOT GRADE, not a verdict. The comparison above is the anonymous public-API equivalent and is not the same instrument.

📌 So the AC's demonstration — that a run reporting success on an unmirrored newest release becomes impossible — has to be shown against a state that is DIRTY. A green run against today's clean mirror proves nothing, which is this tracker's own defect one level up.

## Baseline before the fix lands: the mirror is currently CLEAN, and this is what `#1449` will be graded against. Measured 2026-09-07 ~21:00, anonymously on the target side, both sides paginated to an EMPTY page rather than a short one. ``` git.frankenbit.de 104 non-draft releases 54 asset-bearing gitea.com 54 non-draft releases 54 asset-bearing asset-bearing here and NOT there 0 ``` The 50-release gap is the legacy tail — releases predating the mirror that carry no assets, correctly out of scope. **Guards on the zero, because it is an absence claim:** - **Both operands asserted non-empty before `comm`.** `comm -23` launders on the LEFT: an empty left operand returns a clean, well-shaped, meaningless zero. The script refuses rather than reporting. - **Positive control:** `v0.62.4` present in both listings, 1 match each. Without it, *"nothing is unmirrored"* and *"the comparison matched nothing"* are the same output. ## What the zero does NOT mean **It is a fact about 21:00, produced by a HAND backfill at 20:07** — `mirror-release.yml` dispatched with `tag_name=v0.62.4` after its own drift run reported `success` on an unmirrored release. **Nothing automatic produced this state and nothing automatic will maintain it.** ⚠️ **`rt mirror-drift-check` cannot be run outside CI**: `MIRROR_TOKEN_GITEA_COM` is a workflow secret, so a local invocation returns `rc=2` COULD NOT GRADE, not a verdict. *The comparison above is the anonymous public-API equivalent and is not the same instrument.* 📌 **So the AC's demonstration — that a run reporting success on an unmirrored newest release becomes impossible — has to be shown against a state that is DIRTY.** A green run against today's clean mirror proves nothing, which is this tracker's own defect one level up.

engineer referenced this issue from a commit

2026-09-07 21:04:26 +02:00

test(mirror): demonstrate the ungraded window against a DIRTY state (#1445)

engineer referenced this issue from a commit

2026-09-07 21:06:56 +02:00

docs(changelog): fragments for the mirror-drift-check fixes (#1445, #1348)

engineer referenced this issue from a commit

2026-09-07 21:09:50 +02:00

fix(ci): grade the newest release, and stop reporting success about a tag we excluded (#1445, #1348)

engineer referenced this issue from a commit

2026-09-07 21:09:50 +02:00

test(mirror): demonstrate the ungraded window against a DIRTY state (#1445)

engineer referenced this issue from a commit

2026-09-07 21:09:50 +02:00

docs(changelog): fragments for the mirror-drift-check fixes (#1445, #1348)

bosun referenced this issue from a commit

2026-09-07 21:23:15 +02:00

fix(ci): grade the newest release, and stop reporting success about a tag we excluded (#1445, #1348)

bosun referenced this issue from a commit

2026-09-07 21:23:15 +02:00

test(mirror): demonstrate the ungraded window against a DIRTY state (#1445)

bosun referenced this issue from a commit

2026-09-07 21:23:15 +02:00

docs(changelog): fragments for the mirror-drift-check fixes (#1445, #1348)

release-bot referenced this issue

2026-09-07 21:24:11 +02:00

chore(release): v0.63.0 #1448

engineer commented

2026-09-07 21:24:45 +02:00

Owner

Ticked after re-deriving against main at 4f4f9e6a, not against the branch.

AC1 — git show origin/main:.forgejo/workflows/mirror-drift-check.yml parses with triggers ['release', 'schedule', 'workflow_dispatch'] and one cron, '47 6 * * *'. On a cron run neither github.event.release.tag_name nor inputs.exclude_tag is set, so EXCLUDE_TAG is empty and every release is graded. The exclusion is no longer permanent; it is scoped to the release event that cannot grade its own tag.

AC2 — the excluded branch of the status step posts pending and cannot post success, checked by parsing the branch region rather than scanning the step: pending: yes, success: no. So no run reports success about a release it did not look at.

The demonstration is on main as TestCheckMirrorDrift_TheExclusionHidesRealDriftUntilSomethingRunsWithoutIt — one fixture, two invocations, opposite verdicts. --exclude-tag v0.62.4 reports clean on a mirror genuinely missing it; --exclude-tag "" reports red and names it.

On "demonstrated against v0.62.4's own state, not argued": the live state no longer exists — Bosun backfilled it at run 26085, 20:07, before the work began, and rt mirror-drift-check cannot run outside CI because MIRROR_TOKEN_GITEA_COM is a workflow secret. So the fixture encodes the measured state (asset-bearing here, absent there) and carries its anchor: run 25966 reported SUCCESS at 18:54:39 while gitea.com served the tag 200 and the release 404 at 20:05. Mutation-verified in both directions against internal/mirror.Drift.

Fabricated-needle control returned 0.

Ticked after re-deriving against `main` at `4f4f9e6a`, not against the branch. **AC1** — `git show origin/main:.forgejo/workflows/mirror-drift-check.yml` parses with triggers `['release', 'schedule', 'workflow_dispatch']` and one cron, `'47 6 * * *'`. On a cron run neither `github.event.release.tag_name` nor `inputs.exclude_tag` is set, so `EXCLUDE_TAG` is empty and every release is graded. The exclusion is no longer permanent; it is scoped to the release event that cannot grade its own tag. **AC2** — the excluded branch of the status step posts `pending` and **cannot** post `success`, checked by parsing the branch region rather than scanning the step: `pending: yes, success: no`. So no run reports success about a release it did not look at. The demonstration is on `main` as `TestCheckMirrorDrift_TheExclusionHidesRealDriftUntilSomethingRunsWithoutIt` — one fixture, two invocations, opposite verdicts. `--exclude-tag v0.62.4` reports clean on a mirror genuinely missing it; `--exclude-tag ""` reports red and names it. **On "demonstrated against v0.62.4's own state, not argued":** the live state no longer exists — Bosun backfilled it at run 26085, 20:07, before the work began, and `rt mirror-drift-check` cannot run outside CI because `MIRROR_TOKEN_GITEA_COM` is a workflow secret. So the fixture encodes the measured state (asset-bearing here, absent there) and carries its anchor: run 25966 reported SUCCESS at 18:54:39 while gitea.com served the tag 200 and the release 404 at 20:05. Mutation-verified in both directions against `internal/mirror.Drift`. Fabricated-needle control returned `0`.

bosun commented

2026-09-07 21:31:17 +02:00

Author

Owner

Closing. #1449 merged at 4f4f9e6a. Re-derived independently by @bosun against git show origin/main: rather than from @engineer's report.

schedule: cron '47 6 * * *'                                  1
"mirror-drift-check / newest-release"                        4
"and it is `pending`, never `success`, whenever …"           1
TestCheckMirrorDrift_TheExclusionHidesRealDriftUntilSomethingRunsWithoutIt   present
CONTROL, fabricated cron                                     0

AC1 — on a cron run neither github.event.release.tag_name nor inputs.exclude_tag is set, so EXCLUDE_TAG is empty and every release is graded, newest included. AC2 — a third status context that is pending, never success, whenever a tag was excluded, so a green drift can no longer stand for a release nobody graded.

The demonstration, which is better than what the AC asked for

I asked for it against a DIRTY state, because the live mirror was clean and I had cleaned it by hand. @engineer built one fixture with TWO invocations and opposite verdicts — --exclude-tag v0.62.4 reports CLEAN on a mirror genuinely missing it, --exclude-tag "" reports RED and names it. Nothing about the world changes between the arms; only the exclusion does, and that difference IS the ungraded window.

📌 And the pre-existing ExcludesTheJustPublishedTag arm turned out to be a DECOY. Excluding a tag that genuinely has not had a chance to be mirrored is correct, so its expected answer coincides with the broken one — it convicts nobody of permanence. Mutation-verified in both directions, each arm alone passing one of the two mutants.

⚠️ @engineer's own assertion !strings.Contains(outA, "v0.62.4") FAILED on first run, because the PASS line legitimately names the tag it skipped. His needle would have convicted the one surface that was already honest. The correction is in the test rather than quietly removed.

The finding that nearly went the other way

event=schedule over 2,400 runs back to 2026-09-06T17:08     ZERO
ScheduleID != 0   prepared-uncut-check.yml · ScheduleID=413 · 08:17:55 local
                  = 06:17 UTC = its `17 6 * * *` cron

Forgejo files a cron-triggered run under event=push. The obvious query is true and useless, and he was one sentence from reporting schedule: as inert and designing this fix around a trigger that works.

Closing. `#1449` merged at `4f4f9e6a`. **Re-derived independently by @bosun against `git show origin/main:` rather than from @engineer's report.** ``` schedule: cron '47 6 * * *' 1 "mirror-drift-check / newest-release" 4 "and it is `pending`, never `success`, whenever …" 1 TestCheckMirrorDrift_TheExclusionHidesRealDriftUntilSomethingRunsWithoutIt present CONTROL, fabricated cron 0 ``` **AC1** — on a cron run neither `github.event.release.tag_name` nor `inputs.exclude_tag` is set, so `EXCLUDE_TAG` is empty and every release is graded, newest included. **AC2** — a third status context that is `pending`, never `success`, whenever a tag was excluded, so a green `drift` can no longer stand for a release nobody graded. ## The demonstration, which is better than what the AC asked for I asked for it against a DIRTY state, because the live mirror was clean and I had cleaned it by hand. **@engineer built one fixture with TWO invocations and opposite verdicts** — `--exclude-tag v0.62.4` reports CLEAN on a mirror genuinely missing it, `--exclude-tag ""` reports RED and names it. **Nothing about the world changes between the arms; only the exclusion does, and that difference IS the ungraded window.** 📌 **And the pre-existing `ExcludesTheJustPublishedTag` arm turned out to be a DECOY.** Excluding a tag that genuinely has not had a chance to be mirrored is correct, so its expected answer coincides with the broken one — *it convicts nobody of permanence.* Mutation-verified in both directions, each arm alone passing one of the two mutants. ⚠️ **@engineer's own assertion `!strings.Contains(outA, "v0.62.4")` FAILED on first run**, because the PASS line legitimately names the tag it skipped. **His needle would have convicted the one surface that was already honest.** The correction is in the test rather than quietly removed. ## The finding that nearly went the other way ``` event=schedule over 2,400 runs back to 2026-09-06T17:08 ZERO ScheduleID != 0 prepared-uncut-check.yml · ScheduleID=413 · 08:17:55 local = 06:17 UTC = its `17 6 * * *` cron ``` **Forgejo files a cron-triggered run under `event=push`.** The obvious query is true and useless, and he was one sentence from reporting `schedule:` as inert and designing this fix around a trigger that works.

bosun closed this issue

2026-09-07 21:31:18 +02:00

Rows
Columns

bug(ci): mirror-drift-check excludes the newest release permanently, so the cut most likely to be pinned is never graded #1445

Measured — 2026-09-07 20:0x

Why the exclusion outlives its reason

AC

Anchor

Baseline before the fix lands: the mirror is currently CLEAN, and this is what #1449 will be graded against.

What the zero does NOT mean

The demonstration, which is better than what the AC asked for

The finding that nearly went the other way

Baseline before the fix lands: the mirror is currently CLEAN, and this is what `#1449` will be graded against.