S3 sagt 200 OK. Dein Upload ist trotzdem kaputt.

Das Problem liegt nicht immer im Statuscode

Ein S3 Multipart Upload besteht aus mehreren Teilen: Upload starten, Parts übertragen, Parts abschließen. Der kritische Schritt ist CompleteMultipartUpload. Genau dort reicht eine Prüfung auf HTTP 200 nicht aus.

Der Abschluss-Call kann mit 200 OK antworten und trotzdem einen Fehler im Body liefern. Wer im HTTP-Client nur response.ok oder den Statuscode auswertet, kann den Upload als erfolgreich verbuchen, obwohl kein verwendbares Objekt entstanden ist. Das ist besonders unerquicklich, wenn danach Datenbankeinträge geschrieben, Folgeprozesse gestartet oder Nutzer über einen erfolgreichen Import informiert werden.

Vereinfacht sieht die problematische Antwort so aus:

<Error>
  <Code>...</Code>
  <Message>...</Message>
</Error>

Die Regel für mich: CompleteMultipartUpload 200 Error ist kein exotischer Sonderfall, den man ignorieren darf. Der Response-Body gehört zur Erfolgsauswertung.

Erfolg in drei Schritten prüfen

Eine robuste Pipeline trennt Transporterfolg und fachlichen Erfolg.

1. Status und Response-Body von CompleteMultipartUpload prüfen.
2. Das erwartete Objekt mit HEAD abfragen.
3. Die zurückgemeldete Objektgröße mit der erwarteten Gesamtgröße vergleichen.

Bei einem XML-basierten Client bedeutet der erste Schritt: Einen Error-Body nicht als Erfolg parsen oder behandeln. Bei einem SDK sollte klar sein, wie es eingebettete Fehler und Streaming-Antworten behandelt. Ich würde mich dabei nicht allein auf die Abstraktion des SDKs verlassen, sondern den tatsächlich ausgewerteten Response-Pfad testen.

Ein typisches TypeScript-Schema kann so aussehen:

async function verifyUpload(
  key: string,
  expectedBytes: number,
  completeResult: { hasEmbeddedError: boolean },
  headObject: (key: string) => Promise<{ contentLength?: number }>
) {
  if (completeResult.hasEmbeddedError) {
    throw new Error("Multipart-Abschluss enthält einen Fehler im Body");
  }
 
  const object = await headObject(key);
 
  if (object.contentLength !== expectedBytes) {
    throw new Error("Objektgröße stimmt nicht mit der erwarteten Größe überein");
  }
}

Die HEAD-Abfrage ersetzt nicht die Body-Prüfung. Sie ergänzt sie. Der Abschluss kann fehlgeschlagen sein; dann darf die Pipeline keinen Erfolg melden. Umgekehrt zeigt HEAD, ob das Objekt unter dem erwarteten Key tatsächlich vorhanden ist und die erwartete Größe hat.

Die erwartete Größe muss aus der Pipeline kommen

Für den Größenvergleich braucht der Upload-Prozess eine verlässliche Sollgröße. Bei einer Datei ist das normalerweise die bekannte Dateigröße vor dem Start. Bei einem Stream muss die Anwendung festlegen, wo sie die beim Lesen gezählten Bytes speichert und wie sie einen Abbruch behandelt.

Angenommen, eine Anwendung erwartet eine Datei mit einer bestimmten Bytezahl. Nach dem Multipart-Abschluss liefert HEAD eine andere Content-Length. Dann ist das kein Detail für ein Debug-Log, sondern ein fehlgeschlagener Upload. Das Objekt sollte nicht als fachlich gültig weiterverarbeitet werden.

ETag ist bei Multipart kein Dateihash

Ein weiterer häufiger Fehler betrifft die Integritätsprüfung. Der S3 ETag Multipart ist kein MD5-Hash der gesamten Datei. Deshalb taugt er nicht als allgemeiner Vergleichswert zwischen lokaler Datei und gespeichertem Multipart-Objekt.

Wenn die Anwendung einen Integritätsnachweis braucht, sollte sie beim Lesen der Datei selbst einen Hash berechnen und ihn als Objektmetadatum speichern. Nach dem Upload kann die Pipeline dieses Metadatum auslesen und gegen den erwarteten Wert prüfen.

const metadata = {
  "content-sha256": calculatedSha256
};

Wichtig ist die Reihenfolge: Der eigene Hash ergänzt die Prüfung per HEAD und Größenvergleich. Er macht den Statuscode nicht aussagekräftiger und ersetzt nicht die Prüfung des Abschluss-Responses.

Offene Multipart-Uploads vorsichtig aufräumen

Fehlgeschlagene oder abgebrochene Uploads können offen bleiben. Aufräumen ist sinnvoll, darf aber nicht pauschal alle offenen Uploads entfernen. Sonst kann ein Bereinigungsjob einen parallel laufenden, legitimen Upload abbrechen.

Ich würde deshalb nur Uploads mit einer klaren Altersgrenze bereinigen, etwa solche, die älter als eine Stunde sind. Die passende Grenze hängt von der erwarteten Upload-Dauer ab. Entscheidend ist das Prinzip: Ein Upload darf erst dann als verwaist gelten, wenn er ausreichend lange keine reguläre Ausführung mehr sein kann.

Was eine belastbare Pipeline ausmacht

Wer einen AWS S3 Upload prüfen will, braucht mehr als einen grünen HTTP-Status: Response-Body auswerten, Objekt per HEAD prüfen, Größe vergleichen und bei Bedarf einen eigenen Hash verifizieren. Damit wird aus einem vermeintlichen Transporterfolg ein nachvollziehbarer, fachlicher Erfolgsnachweis.

Prüft eure Upload-Pipeline: Woran erkennt sie einen kaputten Upload?