- Expédié
- 5 septembre 2026 à 00:02 UTC
- Auteur
- Kamo
- Commite
- 1e6e50f
Les deux versions précédentes (2862548, dd323bc) ont toutes deux produit des images qui n'ont pas pu être tirées: lire courte: attendue 3985350 octets mais obtenu 0: EOF inattendu Cause: le registre était tenu un LINK à la couche per-repo pour chacun de ces condensés, tandis que le blob DATA sous blobs/sha256/xx-/digest/données avait disparu. vu le lien, a conclu que la couche était déjà présenter et vider le téléchargement; pull a alors obtenu 200 avec zéro octets. La reconstruction ne pouvait pas y remédier. parce que chaque reconstruction a produit les mêmes digests et a sauté les mêmes couches - c'est pourquoi le Une première reconstruction reproduit exactement l'échec. 396 des 446 liaisons de couche de ce repo étaient suspendues; les 396 ont été enlevés (chacun revérifié comme suit: n'ayant pas de données blob d'abord), laissant les 50 intactes seules. Sans lien à trouver, cette poussée télécharge ces couches au lieu de les sauter. L'échantillonnage montre la même condition de liaison pendante à travers chaque prise dans le registre, donc c'est un Problème d'intégrité à l'échelle du registre qui se trouve fatal uniquement ici - ailleurs dans le registre 404 le blob manquant et les re-uploads en pression. Une cause probable est une GC qui enlève les blobs sans élagage les liaisons per-repo.