Stop a slow CDN from eating the release it is checking - #160
Merged
Merged
Conversation
The resolution check this added in 2.3.0 did its job and cost that release its record. Central published all eleven artifacts and its CDN had not finished serving three of them inside the ten minutes the check allowed, so the step failed — and because it sat second-to-last, it skipped the four steps after it. 2.3.0 was live and resolvable on Maven Central with no GitHub Release, no binaries attached and no artifact metadata. All of that was created by hand afterwards, from the workflow's own extraction. The ordering was the mistake. A check reports on what happened; it does not decide whether the thing that happened gets written down. It runs last now, so a slow CDN still turns the run red and still says which artifacts are missing, and the release record exists either way. The waiting was the second mistake. Thirty attempts of twenty seconds per module, sequentially, made the worst case the sum of eleven timeouts. It polls the whole set each round now, so the budget is half an hour for the slowest rather than half an hour each.
|
This pull request adds no capability the code did not already have. 2 files read · 1044 ms · against |
tonytonycoder11
deleted the
fix/a-slow-cdn-should-not-eat-the-release
branch
September 12, 2026 11:09
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 resolution check added in
2.3.0worked, and cost that release its record.What happened
Central published all eleven artifacts. Its CDN had not finished serving three of them —
kdrant-bom,kdrant-coreandkdrant-transport-rest— inside the ten minutes per module the check allowed, so thestep failed after 38 minutes and reported exactly that. Correct, as far as it goes.
The step sat second-to-last, so failing skipped the four after it:
2.3.0was live and resolvable on Maven Central with no Release object, no binaries and no artifactmetadata. All three were created by hand afterwards: the Release from the workflow's own
awkextraction,the binaries from the run's
cli-*artifacts, and the ten storage records from digests computed over thejars as Central serves them.
Every artifact resolves now, including the three the check gave up on. It was a race with a CDN, not a
failed publish.
The two fixes
Ordering. A check reports on what happened; it does not decide whether the thing that happened gets
written down. It runs last now. A slow CDN still turns the run red and still names the artifacts that are
missing, and the release record exists either way.
Waiting. Thirty attempts of twenty seconds per module, sequentially, made the worst case the sum of
eleven timeouts. It polls the whole set each round now, so the budget is half an hour for the slowest rather
than half an hour each. The summary also says that the release is recorded regardless, so whoever reads a
red run knows what they are looking at.
Why this is not a new check
It is the same check. What changed is that it can no longer destroy the evidence of the release it is
checking, which is the property it should have had when it was written.