Skip to content

Stop a slow CDN from eating the release it is checking - #160

Merged
tonytonycoder11 merged 1 commit into
mainfrom
fix/a-slow-cdn-should-not-eat-the-release
Sep 12, 2026
Merged

tonytonycoder11 merged 1 commit into
mainfrom
fix/a-slow-cdn-should-not-eat-the-release

Conversation

@tonytonycoder11

Copy link
Copy Markdown
Contributor

The resolution check added in 2.3.0 worked, 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-core and kdrant-transport-rest — inside the ten minutes per module the check allowed, so the
step 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:

  Publish to Maven Central                      success
  Check the release resolves from Maven Central  failure
  Create the GitHub Release                      skipped
  Fetch the CLI binaries                         skipped
  Attach the CLI binaries to the Release         skipped
  Record the published artifacts                 skipped

2.3.0 was live and resolvable on Maven Central with no Release object, no binaries and no artifact
metadata. All three were created by hand afterwards: the Release from the workflow's own awk extraction,
the binaries from the run's cli-* artifacts, and the ten storage records from digests computed over the
jars 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.

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.
@tonytonycoder11
tonytonycoder11 requested a review from a team as a code owner September 12, 2026 11:05
@trueup-by-nacode-studios

Copy link
Copy Markdown

This pull request adds no capability the code did not already have.

2 files read · 1044 ms · against cf173fc · engine 1.4.1

@tonytonycoder11 tonytonycoder11 moved this to In progress in Kdrant Sep 12, 2026
@tonytonycoder11
tonytonycoder11 merged commit 2874572 into main Sep 12, 2026
14 checks passed
@tonytonycoder11
tonytonycoder11 deleted the fix/a-slow-cdn-should-not-eat-the-release branch September 12, 2026 11:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

1 participant