An artifact surviving the failed run may defeat the Re-run all jobs recovery D4.5 now prescribes

[ptr727]

WORKFLOW.md D4.5, as of #1215, names Re-run all jobs as the recovery for a failed package push whose branch tip has moved. That route re-executes the build leaves, which re-upload their artifacts under fixed names into a run that may still hold artifacts of those names. Whether that succeeds decides whether the documented recovery works, and nothing in the tree settles it.

The collision

Every build leaf uploads under a fixed, branch-suffixed name with actions/upload-artifact pinned at v7.0.1, and none sets overwrite:

• .github/actions/nuget-build-default/action.yml uploads nuget-build-<branch> and release-asset-<branch>-nuget
• .github/actions/pypi-build-default/action.yml uploads pypi-build-<branch>
• .github/actions/dotnet-publish-default/action.yml uploads release-asset-<branch>-dotnet-publish

That action's own README states the default: "If false, the action will fail if an artifact for the given name already exists." Artifacts belong to the run rather than to one attempt, so a re-run of a run that still holds the name would hit it.

Why the recovery reaches that case

D5.2 gates the package-artifact delete on !cancelled() && steps.<download-step-id>.outcome == 'success', so on the ordinary failed-push path the delete runs and the name is free. Two paths leave it occupied:

1. D5.3 leaves the delete best-effort. continue-on-error: true plus a script that turns a failed DELETE into a ::warning:: means a failed delete is silent, and the artifact survives.
2. On a re-run replaying a push event with the tag already cut, D4.4's no-op leg skips the release-create, and D5.2 skips the paired release-asset-* delete with it. That one is deterministic rather than a best-effort failure, so a second full re-run meets an occupied name by design.

retention-days: 1 (D5.4) bounds the window to roughly a day, which is exactly when an operator reaches for the recovery.

The contradictory evidence in the tree

.github/workflows/build-release-task.yml's asset-delete step comments "It deletes every matching id, because a rerun can upload duplicates". That asserts a re-run does upload a duplicate name, which reads as pre-v4 upload-artifact behaviour that the pinned v7 no longer has. D5.3's "deletes all matching ids" rule exists for that same older reading. One of the two is stale and the contract now leans on which.

What needs deciding

1. Set overwrite: true on the build leaves' uploads. Dissolves the collision, makes the recovery unconditional, and retires the "a rerun can upload duplicates" comment and D5.3's all-ids rationale if they are indeed stale.
2. Leave it and document the bound. D4.5 gains a fourth qualification saying the full re-run reds at the upload where an artifact survived, and that --failed is the route in exactly that case.
3. The collision does not occur for a reason not yet identified, in which case the comment above is stale and should say so.

Verification owed

GitHub documents nothing about artifact visibility across run attempts, in either the action README or the re-run docs. Settling this needs a real run: fail a package push, let the delete fail or take the skipped-delete path, then Re-run all jobs and observe whether the leaf's upload succeeds. That is a real publish against a real registry, so it is the maintainer's to run rather than an agent's.

Related

Found by the adversarial passes on #1215, which documented the recovery this bears on. Related to #1200 and #1212, which carry the other section 4 and condensed-catalog defects.

[ptr727]

Three more independent raises of this, and one piece of evidence that makes the live check decisive rather than merely wanted.

Raised again, four times across two pull requests. CodeRabbit raised it on #1215 as an outside-diff finding, and on #1223 both CodeRabbit (Major, twice) and Qodo (Bug, High) raised it against D4.5's text. Two independent reviewers, four raises. That is a strong signal the exposure is real rather than theoretical.

The decisive evidence: the repository contradicts itself about the mechanism.

.github/workflows/build-release-task.yml:371, commenting the release-asset delete loop:

It deletes every matching id, because a rerun can upload duplicates.

That asserts a re-run can upload a duplicate under a name the run already holds, and the loop exists to clean up the duplicates it expects. The premise behind every version of this finding is the opposite: that actions/upload-artifact rejects a name the run already holds unless overwrite: true.

Both claims now live in the tree and nothing settles which governs. The dates do not settle it either: the comment landed 2026-08-16 in #762, and the current v7.0.1 pin landed 2026-09-01 in #1162, so the comment may predate the behaviour it describes, but that is an inference rather than evidence.

Why this blocked a prose fix. I attempted to state the bound in D4.5 as a precondition on the recovery, in response to those reviewer findings. A whole-unit review pass rejected it on two grounds, both of which I verified:

1. The new sentence rests on a premise build-release-task.yml:371 describes in reverse, so the contract would carry a claim the workflow contradicts, and it would be carried fleet-wide the moment either file is.
2. The bound is wider than any precondition I could state. The leaves upload four fixed-name artifacts, not two: nuget-build-<branch> and pypi-build-<branch> are the package artifacts, while release-asset-<branch>-nuget (.github/actions/nuget-build-default/action.yml:88) and release-asset-<branch>-dotnet-publish (dotnet-publish-default/action.yml:102) are release assets deleted by a different step in a different job. A precondition naming only the package artifact leaves a reachable case with no route at all: the release-asset delete's listing call fails, every release-asset-* survives, the package artifact's own delete succeeds, so --failed cannot run and the full re-run collides at a release-asset upload instead.

So the prose fix was abandoned rather than shipped, and the finding stands here.

What this adds to the decision. Whichever option is taken, the build-release-task.yml:371 comment has to be reconciled in the same change, since it is the tree's own statement of the opposite mechanism. And the live check named above now needs to cover the release-asset artifacts as well as the package ones, because those are the set with no alternative route.