fix(release): retry the tag verify read after createRef - #11
Merged
Conversation
The read-after-write of refs/tags/<version> can lag GitHub's replication; 2 of the first 3 production releases failed with 'Tag X points to null' despite the tag existing at the expected SHA moments later. Retry the verify up to 10 times with a 2s backoff before failing. Reruns recovered both incidents, confirming the create itself succeeds.
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
1 participant
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 tag-registration step creates refs/tags/ and immediately re-reads it to verify the SHA. That read-after-write can lag GitHub's replication: 2 of the first 3 production releases (quickadd 2.19.1, MetaEdit 1.10.2) failed with 'Tag X points to null, expected ' while the tag already existed at exactly the expected SHA - both recovered on a plain rerun.
This bounds the verify with a retry loop (10 attempts, 2s backoff, ~20s ceiling) mirroring the existing waitForDraftReleaseTag pattern further down the file. The mismatch error is unchanged when the tag resolves to a genuinely wrong SHA.