- Verschifft
- 27. August 2026 um 05:24 UTC
- Autor
- Kamo
- Ausschuss
- f848f39
Ein Mitglied schickte eine 11 MB .wav zu einem Chat, bekam "Kann nicht aufrufen ObjectWriteResponse.etag() weil die Antwort null ist", wieder gesendet, und die zweites sofort geliefert - zeigt auf Bytes, die nie gespeichert wurden. Jeder versuchen, es zu spielen 500'd mit "Objekt existiert nicht". Zwei Defekte in Serie. minio-java 8.5.7 hat ein drittes Ergebnis für putObject, das weder ein Ergebnis noch eine Ausnahme: Wenn ein MULTIPART Upload fehlschlägt und der Ausgleich abbricht, dann SUCCEEDS, S3Base.putMultipartObjectAsync fällt aus dem Fangblock und kehrt zurück die immer noch-null Antwort statt Umwerfen (Bytecode Offsets 147-171 -226-228). Lesen seines Etag warf eine NullPointerException, die nicht in der pro-Knoten-Fang ist Liste - so entkam es der Ausfallschleife und die restlichen MinIO-Knoten waren nie versucht. Behandeln Sie stattdessen ein Null-Schreib-Ergebnis als fehlgeschlagenen Knoten: Die Schleife bewegt sich weiter, und Wenn jeder Knoten ausfällt, wird dem Anrufer mitgeteilt, dass das Objekt nicht gespeichert wurde. Die Reihe überlebte es. storeContentAddressed schreibt die ImgDat mit isMissing=true VOR die Bytes gehen zur Lagerung, die absichtlich ist - ein Absturz muss eine Reihe verlassen das zugibt, es hält nichts. Aber keine dedup Lookup überprüft, dass Flagge, so dass die Toten Reihe war ein perfekt gutes Spiel, und der Streaming-Pfad ist nicht @Transactional so Nichts rollte es zurück. Jede Dedup-Abfrage passt jetzt nur noch veröffentlichten Inhalt, und ein gefangener Upload-Fehler wirft die Zeile, die er gerade geschrieben hat. Nur mehrteilige Uploads können auf diese Weise scheitern, so war es für kleine Dateien unsichtbar und wartete auf genau die großen ein Mitglied verlieren.