Repository navigation
ci: let the push decide the publish, not a poll that cannot know - #71
Merged
Merged
Conversation
The first real release proved the verification step wrong. It polled the flat container for ten minutes and failed the run, while the push had in fact succeeded: nuget.org accepted both packages at 21:24 and made them restorable shortly after the poll gave up at 21:34. The bound was not the mistake — the idea was. Nothing anonymous reflects an accepted package before validation finishes: not the flat container, the registration, the search index, or the package page. Only the signed-in owner sees it, marked "Validating", and nuget.org's own guidance allows up to an hour. A poll therefore cannot separate "accepted, validating" from "refused" inside any budget worth a runner, which is the single distinction it existed to draw. Nor is post-push verification a practice this ecosystem follows. The defect it was built for is closed where it happens instead. Dropping --skip-duplicate makes a 409 fail the push itself, immediately, carrying the gallery's own message — including the ID prefix reservation that once passed as success across two dispatches. Retrying a dispatch after a partial push now aborts on the package that already landed, which is a decision for whoever dispatched it rather than something to swallow. The GitHub Packages lane keeps the flag: a duplicate there is benign, that registry has no reserved namespaces, and its versions can be deleted.
Blind-Striker
force-pushed
the
ci/publish-verification-rethink
branch
from
September 8, 2026 21:45
613c55c to
fa659b1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The first real release proved the verification step I added earlier today wrong. It polled the flat container for ten minutes and failed the run, while the push had in fact succeeded.
Measured on run 34279340414:
Push to NuGet.orgVerify NuGet.org publicationBoth
OpenCodeAI.SdkandOpenCodeAI.Sdk.Extensions0.8.0-preview.1are live and owned byOpenCode.NET. The red run was a false alarm.The bound was not the mistake — the design was
Nothing anonymous reflects an accepted package before validation finishes. Measured while the run was still polling:
Only the signed-in owner sees it, marked Validating, and nuget.org's own guidance allows up to an hour. So a poll cannot separate "accepted, validating" from "refused" within any budget worth spending a runner on — which is the one distinction it existed to make. Raising the bound to an hour would hold a runner for an hour per release and still not make the signal sound.
The defect it was built for is closed where it happens
Dropping
--skip-duplicatemakes a 409 fail the push itself, immediately, carrying the gallery's own message — including the ID prefix reservation that once passed as success across two dispatches. The cost is that retrying a dispatch after a partial push aborts on the package that already landed; that is a decision for whoever dispatched it, not something to swallow.What remains is a report, not a gate: it says whether each package is restorable yet, and says plainly that validation can take an hour when it is not.
The GitHub Packages lane keeps the flag, where a duplicate is benign and the registry has no reserved namespaces.