- Spegnimento
- 27 agosto 2026 alle ore 05:24 UTC
- Autore
- Kamo
- Impegno
- f848f39
Un membro ha inviato un 11 MB .wav a una chat, ottenuto "Cannot invoke ObjectWriteResponse.etag() perché la risposta è nulla", inviata di nuovo, e il seconda consegnata istantaneamente — puntando a byte che non sono mai state memorizzate. Ogni tentare di giocarlo 500'd con "Object non esiste". Due difetti in serie. minio-java 8.5.7 ha un terzo risultato per putObject che non è né un risultato né un risultato un'eccezione: quando un upload MULTIPART fallisce e l'interruzione di compensazione allora SUCCEEDS, S3Base.putMultipartObjectAsync cade dal suo blocco di cattura e restituisce la risposta continua invece di ricrescere (bytecode offset 147→171→226→228). Leggendo il suo etag ha lanciato un NullPointerException, che non è nella cattura per-nodo elenco — così è sfuggito il loop failover e i restanti nodi MinIO non sono mai stati provato. Trattare un risultato di scrittura null come un nodo fallito invece: il loop si muove, e se ogni nodo fallisce il chiamante viene detto che l'oggetto non è stato memorizzato. La fila è sopravvissuta. storeContent Rivolto scrive il ImgDat con isMissing=true Prima che i byte vadano a stoccaggio, che è deliberato — un crash deve lasciare una fila che ammette che non ha niente. Ma nessuno ha controllato la bandiera, quindi i morti. riga era una corrispondenza perfettamente buona, e il percorso di streaming non è @Transactional quindi Niente l'ha rimboccato. Ogni query dedup ora corrisponde solo ai contenuti pubblicati, e un errore di upload catturato scarta la riga che ha appena scritto. Solo gli upload multipart possono fallire in questo modo, quindi era invisibile per i piccoli file e ha aspettato esattamente quelli grandi un membro la maggior parte delle menti che perdono.