Tell a missing arch apart from one that did not read - #282
Merged
Conversation
hexpm/elixir:1.16-erlang-26.2.5.15-alpine-3.21.5 is a single-arch amd64 manifest in the registry as of 2026-07-30 02:24, though both per-arch images have been there since 2025-10-09. fetch_tag/2 answered nil both for a 404 and for a 200 whose body carried no usable image data, and get_archs/2 dropped the arch either way, so one unreadable response was enough for manifest.sh to run imagetools create with a single source and rewrite the multi-arch index as a copy of it. fetch_tag/2 now answers :not_found or :unreadable, and the manifest is published only when every arch answered. A 404 still means the tag is absent, which is how a manifest gets published while the second arch is still building. add_docker_tag/4 merged the reported archs into the row, so a manifest that lost one still read as complete and manifest_mismatches/3 compared against a row claiming both. That is why this survived: the re-publish recorded the loss as a no-op and nothing looked wrong until the next reconcile replaced the row. The row now takes the archs it is given. Docker Hub's tag API is the source of the bad reads. It currently reports 1.20.2-erlang-29.0.4-debian-trixie-20260713-slim as arm64 only while the registry has both platforms, which is what reconcile writes at 01:00 and what the 02:15 check then acts on. Repairing the broken tag is not part of this.
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.
hexpm/elixir:1.16-erlang-26.2.5.15-alpine-3.21.5is a single-arch amd64 manifest in the registry right now, not a multi-arch index, so arm64 pulls of it get an amd64 image. Both per-arch images have been present since 2025-10-09; the manifest was rewritten at 2026-07-30 02:24 without anything being built.fetch_tag/2returnednilboth when Docker Hub said the tag was gone and when it answered 200 with a body carrying no usable image data, andget_archs/2dropped the arch either way. One unreadable response was enough formanifest.shto runimagetools createwith a single source, which replaces the index with a copy of that one manifest.fetch_tag/2now answers:not_foundor:unreadable, and the manifest is published only once every arch has answered. A 404 still counts as absent, which is how a tag gets a manifest while its second arch is still building.add_docker_tag/4merged the reported archs into the existing row, so the re-publish recorded the loss as a no-op and the row still claimed both archs.manifest_mismatches/3reads that row, so nothing looked wrong afterwards and the tag stayed broken until the next reconcile happened to replace the row. The row now takes the archs it is given, which is also whatswap_docker_tags/2already does.The bad reads come from Docker Hub's tag API. It currently reports
1.20.2-erlang-29.0.4-debian-trixie-20260713-slimas arm64-only while the registry has both platforms — that is what reconcile writes at 01:00, and what the 02:15 check acts on by re-publishing. With this change that re-publish is still churn, but it can no longer degrade the tag.Repairing the already-broken tag is not part of this. Both of its per-arch tags read cleanly, so a
DockerManifestrun rebuilds the index correctly.