Zusammenfassung

  • OpenAI eröffnete den Vorfall um 00:55:27 UTC wegen erhöhter Fehlerraten mit dem Code invalid_prompt.
  • Um 01:39:33 meldete das Unternehmen eine angewandte Abhilfe und Überwachung; um 02:20:19 galten alle betroffenen Dienste als wiederhergestellt. Die öffentliche Zeitspanne beträgt 1:24:52.
  • Der Incident-Datensatz nennt den HTTP-Status nicht. Separat bildet das offizielle Python-SDK eine tatsächliche 400 auf BadRequestError ab und wiederholt sie gewöhnlich nicht.
  • Eine Automation, die aus der Klasse unmittelbar „dauerhaft fehlerhafte Eingabe“ ableitet, kann gültige Aufträge verlieren; pauschale Wiederholung würde dagegen Last und Doppelwirkungen erzeugen.
  • OpenAI veröffentlichte weder Ursache noch Fehlerrate, Geografie, Modell- oder Endpunktliste, Anfragenzahl oder Kundenzahl.

Fehlerklassen sind keine reine Dokumentation. Sie steuern Programme. Ein Zeitüberschreitungsfehler landet in einer Warteschlange, eine Ratenbegrenzung löst Rückzug aus, eine ungültige Eingabe wird häufig endgültig abgewiesen. Der Name verteilt also Arbeit zwischen Anbieter und Kunde.

Der OpenAI-Vorfall zeigt, dass diese Verteilung revidierbar sein muss. invalid_prompt bezeichnete das sichtbare Symptom, doch OpenAI führte einen Dienstvorfall, setzte eine Abhilfe ein und beobachtete die Erholung. Eine unveränderliche Zuordnung im Kundensystem konnte dieses neue Wissen nicht aufnehmen.

Empfangene Klasse und operative Diagnose sind zwei Felder

Ein robustes Ereignismodell speichert zunächst unverändert, was die API geliefert hat: HTTP-Status, Fehlercode, Nachricht und Anfragekennung. Daneben steht die operative Diagnose, etwa „Eingabe prüfen“, „Anbieterproblem vermutet“ oder „Ursache unklar“.

Die erste Spalte ist ein Beleg. Die zweite darf sich ändern, wenn neue Telemetrie vorliegt. Ein sprunghafter Anstieg bei bekannten Anfrageformen, ein passender offizieller Vorfall und erfolgreiche Tests nach der Erholung können die Diagnose von dauerhaft zu vorläufig verschieben, ohne die Originalantwort umzuschreiben.

Diese Trennung verhindert auch die umgekehrte Übertreibung. Ein bestätigter Anbieterincident macht nicht jede gleichnamige Antwort richtig. Tatsächlich fehlerhafte Nutzlasten bleiben möglich und müssen nach wie vor korrigiert werden.

Das SDK implementiert eine sinnvolle Normalannahme

In der offiziellen Python-Bibliothek erzeugt eine 400-Antwort eine BadRequestError. Die dokumentierte Wiederholungsmenge umfasst Verbindungsprobleme, 408, 409, 429 und interne Fehler ab 500. Zwei Wiederholungen sind für geeignete Fehler voreingestellt. Eine ausdrückliche Anweisung im Header x-should-retry wird vor den Statusregeln berücksichtigt.

Eine gewöhnliche 400 fällt dagegen in den Pfad ohne automatische Wiederholung. Das schützt beide Seiten: Ein nicht unterstützter Parameter oder eine ungültige Struktur wird durch exponentielles Warten nicht gültig. Diese Regel beschreibt den Fall einer tatsächlich empfangenen 400; sie belegt nicht den Status der Incident-Antworten.

Deshalb sollte eine Organisation nach diesem Vorfall nicht global alle 400-Antworten freigeben. Sie benötigt eine engere Ausnahme, die Zeit, Fehlerratenabweichung, vorherige Gültigkeit und Anbietersignal gemeinsam bewertet.

Eine Zustandsmaschine kann den Widerspruch abbilden

Zwischen „endgültig abweisen“ und „erneut senden“ gehört ein Quarantänezustand. Dort bleibt der Geschäftsauftrag erhalten, während die Automatisierung prüft, ob er gefahrlos wiederholt werden kann.

Ein möglicher Ablauf lautet: empfangen, klassifizieren, bei Anomalie isolieren, offiziellen Status abgleichen, mit wenigen synthetischen Anfragen testen, begrenzt freigeben und anschließend abgleichen. Jeder Übergang braucht einen Grund und eine Zeitmarke. So lässt sich später erklären, warum ein Auftrag verworfen oder erneut ausgeführt wurde.

Die Freigabe muss Mengen- und Geschwindigkeitsgrenzen haben. Eine Statusseite, die „resolved“ meldet, garantiert nicht, dass jede Kontostufe, jedes Modell und jede Funktion gleichzeitig stabil ist. Eine große Warteschlange kann außerdem selbst eine neue Lastspitze erzeugen.

Anfragekennungen schaffen prüfbare Übergänge

Das Python-SDK stellt bei fehlgeschlagenen APIStatusError-Ausnahmen eine Anfragekennung bereit. Zusammen mit UTC-Zeit, Endpunkt, Modell, SDK-Version, Versuchszahl und internem Auftragskennzeichen verbindet sie die Geschäftsseite mit der Sicht des Anbieters.

Für die Form der Nutzlast genügt häufig ein datensparsamer Fingerabdruck. Er kann zeigen, dass gleichartige Aufrufe vorher erfolgreich waren, ohne den vollständigen Prompt, personenbezogene Daten oder Zugangsdaten in ein Incident-Protokoll zu kopieren.

Diese Belege sind nicht nur für Supportfälle wichtig. Sie erlauben nach der Störung, betroffene Aufträge zu rekonstruieren und zu unterscheiden: tatsächlich ungültig, möglicherweise vom Incident betroffen, bereits erfolgreich wiederholt oder mit unbekanntem Erstresultat.

„Resolved“ ist kein Endzustand der Kundenautomation

OpenAIs strukturierter Datensatz beginnt um 00:55:27 mit der Untersuchung, wechselt um 01:39:33 zu Abhilfe und Beobachtung und endet um 02:20:19 mit der Wiederherstellung. Als betroffen wird APIs genannt; die Auswirkung trägt die Kennzeichnung minor.

Diese Angaben messen nicht die Ausfallzeit eines einzelnen Kunden. OpenAI weist darauf hin, dass Verfügbarkeitswerte über Tarife, Modelle und Fehlertypen aggregiert werden und individuelle Erfahrungen abweichen können. Aus dem Datensatz lassen sich weder ein Fehlernenner noch betroffene Regionen und Organisationen berechnen.

Vor allem kehren verworfene Aufträge nicht zurück, nur weil die öffentliche Meldung schließt. Das Kundensystem muss sie finden, echte Eingabefehler aussortieren, wiederholbare Vorgänge kontrolliert ausführen und das Endergebnis prüfen. Bei Vorgängen mit Nebenwirkungen muss es zuerst feststellen, ob der erste Versuch vielleicht doch wirkte.

Ein guter Vertrag benennt auch seine Unsicherheit

OpenAI hat nicht erklärt, weshalb die Anbieterstörung als invalid_prompt erschien, und den HTTP-Status nicht veröffentlicht. Unbekannt bleiben außerdem Modelle, Endpunkte, Volumen und Ursache. Daher wäre die Behauptung falsch, jede gleichnamige Antwort oder jede 400 im Zeitraum sei ein Anbieterfehler gewesen.

Der belastbare Befund ist struktureller. Eine Fehlerklasse kann ihre übliche Verantwortungsgrenze überschreiten. Automatisierung darf deshalb die empfangene Klasse nicht mit einer unumstößlichen Geschäftsentscheidung gleichsetzen.

Ein revidierbarer Fehlervertrag behält Normalregeln bei und macht Ausnahmen sichtbar: Originalsignal sichern, Diagnose mit Quellen anreichern, Wiederholung auf sichere Vorgänge begrenzen und den Geschäftszustand nachher versöhnen. Damit wird aus einem uneindeutigen 400 weder ein stiller Verlust noch eine unkontrollierte Wiederholung.

Quellen