Zusammenfassung

  • Cloudflare löste Vorfall 238b69fw6l55 am 4. August um 07:12:40 UTC, nachdem Workers ein nicht vorgesehenes globales Temporal-Objekt offengelegt hatte.
  • Temporal.Now meldete den 1. Januar 1970; Date und Date.now() zeigten weiterhin die korrekte Zeit.
  • Worker, die nur bei fehlender nativer Implementierung ein Polyfill installierten, konnten es überspringen und Token, TTLs oder Datumsberechnungen unbemerkt gegen 1970 ausführen.
  • Der getrennte Vorfall qtn3z0pny08n verweigerte Deployments von Workers und Workers for Platforms mit nodejs_compat und einem Kompatibilitätsdatum ab dem 4. August 2026.
  • Cloudflare empfahl vorübergehend, nodejs_compat zu entfernen, und erklärte den Deployment-Vorfall um 03:03:00 UTC für behoben.
  • Für beide Fälle fehlen technische Ursache, betroffene Größenordnung, Kundenschaden und vorbeugende Änderungen; eine ursächliche Verbindung wurde nicht behauptet.

Der Laufzeitfehler lag in einer falschen Zusage

Die Plattform fiel nicht vollständig aus. Sie sagte vielmehr etwas Falsches über ihre Fähigkeiten aus. Ein globales Objekt signalisierte einer Anwendung, dass eine native Temporal-Implementierung vorhanden sei. Deren Uhr blieb jedoch am Unix-Epoch stehen.

Damit konnte eine übliche Schutzlogik ins Gegenteil kippen. Ein Worker lud sein bewährtes Polyfill nicht mehr und verwendete die fehlerhafte native Variante. Cloudflare zufolge entstand dabei kein Fehler. Ein Token konnte formal korrekt aussehen, aber mit Ausgabezeit null und Ablauf 1970 versehen sein; TTL und Datumsarithmetik konnten ebenfalls falsch sein.

Die Abgrenzung ist wichtig. Date und Date.now() blieben korrekt. Betroffen waren nicht automatisch alle Worker, sondern jene Pfade, die Temporal nutzten und ihre Implementierung über eine bedingte Präsenzprüfung auswählten.

Der öffentliche Vorfall bildet nicht den gesamten Expositionszeitraum ab

Vom Öffnen am 3. August um 15:13:33 UTC bis zur Lösung am Folgetag vergingen 57.547,538 Sekunden. Cloudflare erklärte aber, das globale Objekt sei seit dem 30. Juli exponiert gewesen. Eine Kundenprüfung muss daher vor dem Statusbeginn ansetzen.

Zu suchen sind betroffene Versionen, übersprungene Polyfills, unmögliche Zeitstempel, zurückgewiesene Berechtigungen, fehlerhafte Cache-Laufzeiten und persistierte Berechnungen. Die Plattformkorrektur repariert keinen bereits ausgegebenen Token und schreibt keine nachgelagerte Datenbank automatisch um.

Auch die Einstufung als „minor“ quantifiziert diese Folgen nicht. Ohne Zahl der Worker, Anfragen oder Kunden bleibt sie eine Cloudflare-Klassifizierung, keine individuelle Schadensmessung.

Im zweiten Fall stoppte die Kontrollfläche die Änderung

Der Deployment-Vorfall lag vor der Ausführung. Eine Konfiguration mit nodejs_compat und einem Datum ab dem 4. August wurde für Workers und Workers for Platforms abgelehnt. Der Code konnte also gar nicht erst unter der beabsichtigten Konfiguration starten.

Cloudflare wollte die Assertion lockern und nannte das Entfernen des Flags als Umgehung. Das war keine Garantie gleicher Funktion. Benötigt eine Anwendung Node.js-kompatible APIs oder Verhaltensweisen, kann die Entfernung einen sichtbaren Deployment-Fehler gegen einen späteren Laufzeitfehler tauschen.

Der Statuszyklus dauerte 4.000,289 Sekunden. Zahlen zu abgelehnten Releases, Regionen, verpassten Änderungsfenstern oder Folgen des Workarounds veröffentlichte Cloudflare nicht.

Ein Kompatibilitätsdatum ist Teil der Betriebsverantwortung

Kompatibilitätsdaten erlauben einer Plattform, sich zu verändern, ohne jedem Kunden neue Semantik sofort aufzuzwingen. Ein Team wählt damit einen Satz von Verhaltensweisen, testet ihn und nimmt ihn in seine Release- und Rollback-Verfahren auf.

Deshalb muss die Kombination aus Datum, Flags und Produktpfad geprüft werden. Einzelne Optionen können für sich funktionieren und als Matrix scheitern. Cloudflare braucht repräsentative Plattformtests; Kunden können das nächste Datum vor dem eigentlichen Release mit der Produktionskonfiguration als Canary deployen.

Ein belastbarer Rückweg enthält außerdem ein zuletzt geprüftes Datum und eine Zuordnung, welche Abhängigkeit jedes Flag schützt. Diese Vorbereitung übernimmt nicht Cloudflares Verantwortung für die fehlerhafte Assertion. Sie verhindert, dass ein Notbehelf ohne Kenntnis seiner Nebenwirkungen eingesetzt wird.

Verfügbarkeit und Korrektheit brauchen getrennte Messpunkte

Ein HTTP-Monitor konnte beim Zeitfehler grün bleiben, weil der Worker weiter antwortete. Ein Laufzeittest konnte wiederum ein zukünftiges Deployment-Problem nicht erkennen, bevor die Pipeline die neue Kombination verwendete.

Der semantische Canary prüft plausible Zeit, Ausgabe vor Ablauf und positive TTL. Der Kontrollflächen-Canary prüft, ob zukünftiges Datum, echte Flags und derselbe Produktpfad deploybar sind. Keiner ersetzt den anderen.

Für kritische Vorgänge kann die Anwendung zudem unmögliche Zeitwerte ablehnen. Das erhebt Date.now() nicht zur ewig unabhängigen Wahrheit; es prüft die konkrete Invariante, von der der Geschäftsprozess abhängt.

Zwei nahe Vorfälle ergeben noch keine gemeinsame Ursache

Beide Ereignisse betrafen Workers-Releases und endeten am selben Tag. Das rechtfertigt eine übergreifende Prüfung von Staging, Testabdeckung und Rollback. Es belegt aber weder ein gemeinsames Release noch einen gemeinsamen Defekt.

Beim Laufzeitfall sind Fähigkeitsfreigabe, Uhreninitialisierung und semantische Tests zu erklären. Beim Deployment-Fall sind Assertion und Abdeckung der Datum-Flag-Matrix zu erklären. Erst wenn Cloudflare einen technischen Zusammenhang veröffentlicht, lässt sich diese Trennung aufheben.

Bis dahin ist die stärkste gemeinsame Aussage keine erfundene Root Cause, sondern eine beobachtbare Kontrollanforderung: Plattformänderungen müssen vor der Freigabe an beiden Grenzen geprüft werden.

Quellen