- Expédié
- 27 août 2026 à 05:24 UTC
- Auteur
- Kamo
- Commite
- f848f39
Un membre a envoyé un 11 Mo .wav à une discussion, a obtenu "Peut invoquer ObjectWriteResponse.etag() parce que la réponse est nulle", l'a envoyé à nouveau, et le deuxième délivrée instantanément - pointant des octets qui n'ont jamais été stockés. Tous les tenter de le jouer 500'd avec "Object n'existe pas". Deux défauts en série. minio-java 8.5.7 a un troisième résultat pour putObject qui n'est ni un résultat ni une exception: lorsqu'un téléchargement MULTIPART échoue et que l'avorce de compensation alors SUCCEEDS, S3Base.putMultipartObjectAsync sort de son bloc de capture et de ses retours la réponse mortelle au lieu de re-reluter (parté de l'octetcode 147 - 171 - 226) 228. Lecture de son Etag lance un NullPointerException, qui n'est pas dans la prise per-noeud de sorte qu'il a échappé à la boucle de basculement et les nœuds MinIO restants n'ont jamais été épreuve. Traiter un résultat d'écriture nul en tant que nœud défaillant à la place: la boucle se déplace, et si chaque noeud échoue, l'appelant est informé que l'objet n'était pas stocké. La ligne a survécu. storeContentAddressed écrit l'IGmgDat avec isMissing-true AVANT que les octets passent au stockage, qui est délibéré - un accident doit laisser une querelle qui l'admet ne contient rien. Mais aucune recherche dedup n'a vérifié ce drapeau, donc les morts rangée était une parfaite correspondance, et le chemin de streaming n'est pas Rien ne l'a roulé en arrière. Chaque requête dedup correspond désormais au contenu publié uniquement, et un échec de téléchargement pris rejette la ligne qu'il vient d'écrire. Seuls les téléchargements en plusieurs parties peuvent échouer de cette façon, de sorte qu'il était invisible pour les petits fichiers et attendait exactement les grands membres qui perdaient le plus d'esprits.