[Bug]: Release - six version tags have no GitHub Release, and no check detects it

[laurentiu021]

Problem

Six version tags exist with no GitHub Release behind them, and each one has a CHANGELOG entry
announcing it. The repository documents releases that were never published.

Tag	Tagged	CHANGELOG entry
v0.13.6	2026-04-25	yes
v1.7.15	2026-05-22	yes
v1.52.75	2026-07-10	yes
v1.56.7	2026-08-04	yes
v1.65.9	2026-08-14	yes
v1.75.3	2026-08-26	yes

Verified by comparing all 609 version tags against all 603 releases. (A first pass using the default
result limit produced a meaningless list of 400+ "missing" releases; the counts above come from
fetching every release.)

Anyone who follows a tag, or reads the CHANGELOG and goes looking for the matching download, finds
nothing for these six versions.

Why it happens, and why nothing catches it

Tagging and publishing are two separate steps in two separate workflows. auto-release computes the
next version and pushes the tag; the tag then triggers release, which builds and publishes. If the
second step never runs or dies, the tag is already public and the pipeline reports nothing wrong,
because each workflow only ever checks its own step.

CI has a Merged version is tagged job, which confirms the tag appeared. There is no equivalent
check that the release appeared. That is the gap.

Both halves failed today, from different causes:

1. v1.75.2 — auto-release computed v1.75.2 correctly, then the tag push was rejected
   server-side with remote: fatal error in commit_refs. The commit and the version bump were on
   main, so main claimed 1.75.2 with no tag and no release.
2. v1.75.3 — during a GitHub Actions incident (critical, "issue with a database primary"), the
   auto-release job started and was abandoned without completing, and a manually pushed tag then
   produced a release run whose gate job was likewise abandoned, so publishing was skipped.

Both were recoverable by hand once noticed. Noticing was the hard part, and it only happened because
someone was watching the run.

Proposed check

A job that fails when a version tag has no release, and one that fails when the newest CHANGELOG
version has no release. Either can run on a schedule or at the end of the release workflow. The
comparison is two API calls and a set difference, and it must fetch all releases rather than a
default page, which is the trap that made the first pass here useless.

Worth deciding separately: whether the five historical tags get a backfilled release or are left
alone. Backfilling steals the "Latest" badge, which is date-based rather than semver-based, so it
would need --latest re-asserted on the newest release afterwards.

Affected area

.github/workflows/auto-release.yml, .github/workflows/release.yml, .github/workflows/ci.yml.

[laurentiu021]

Update: v1.75.3 is now published, so the list is back to the five historical tags:

v0.13.6, v1.7.15, v1.52.75, v1.56.7, v1.65.9.

Getting v1.75.3 out took three attempts and is a good illustration of why the check in this issue is
worth having:

1. auto-release started and was abandoned mid-flight during the Actions incident, so no tag was
   pushed even though main already carried the version bump.
2. A manually pushed tag produced a Release run whose gate job was abandoned the same way; publishing
   was skipped. That run then sat queued for about 20 hours with zero jobs and never resumed after the
   incident cleared — it had to be cancelled and re-dispatched.
3. The re-dispatch got as far as step 16 of 25. Create GitHub Release received an HTML error page
   instead of JSON, having already uploaded the .exe and .sha256 but not the SBOM, and left the
   release as a draft. Everything after it — all three winget attempts and the Discussions
   announcement — was skipped.

Step 3 is the interesting failure mode for this issue, and it is worse than a missing release: a draft
looks like nothing happened from the outside, while gh release list shows the tag as present. Anything
that checks "does a release exist for this tag" has to check isDraft too, or it will report success on
a release nobody can download.

The recovery was to delete the draft and re-dispatch, which then completed all 25 steps. So a useful
check is not just "tag without a release" but "tag without a published, non-draft release".

[laurentiu021]

The check is in via #2018. The backfill decision stays open, as you asked.

Re-derived the gap list rather than trusting the table here: it is FIVE tags, not six. v1.75.3 was recovered since this was filed. Current state, comparing all 617 version tags against all 612 releases: v0.13.6 · v1.7.15 · v1.52.75 · v1.56.7 · v1.65.9.

Scheduled and standalone, not a step at the end of release.yml. That placement was the tempting one, and it would not have caught either failure: both were runs that never finished, so a verification step inside the same run would have been abandoned with everything else. A separate run on its own trigger is the only shape that notices. Weekly, an hour after the CodeQL sweep, plus workflow_dispatch.

Both halves you specified are implemented: every version tag has a release, and the newest CHANGELOG version has one. The second covers the v1.75.2 shape, where main carried a bump and an entry while neither tag nor release existed.

Your --paginate warning is honoured and commented in place as load-bearing. I also added a vacuity floor that you did not ask for and that turned out to matter: fewer than 100 of either tags or releases means one of the reads failed, and the job errors rather than passing by comparing nothing against nothing. Without it an expired token would have turned this check into a permanent green — the exact failure mode it exists to prevent.

The five gaps are allowlisted rather than backfilled, so the check can go in green today. A ::warning:: fires if an allowlisted tag later gains a release, so a stale entry cannot silently hide a real regression on that same tag.

Verified by extracting both step bodies from the YAML and running them locally rather than retyping: they pass on the real repository, fail when one allowlisted tag is removed, fail when the CHANGELOG claims an unpublished version, and fail via the vacuity floor when the release read returns nothing. The first vacuity attempt exited 1 from a SIGPIPE rather than from the floor — right code, wrong reason — so it was redone to assert the floor's own message.

Leaving this open for the backfill call: publishing five old releases steals the Latest badge (GitHub assigns it by date, not semver) and needs --latest re-asserted afterwards, which is an outward-facing change to five public pages rather than a code decision.

[laurentiu021]

Reopened, and my mistake: the PR carried Closes #1997 while the comment above says the backfill decision stays open. The two disagreed, and the auto-close won.

Narrowing this to the one open half: whether the five historical tags get a backfilled release. The detection gap you described is closed — the check is in and proven — so what is left is an outward-facing call on five public pages, including re-asserting the Latest badge afterwards.