Apps erkennen, die direkt nach dem Publizieren abstürzen

Am 25. September wurden drei Publishes als erfolgreich markiert, obwohl die API der App bei jedem Start nach wenigen Sekunden abstürzte. Weil sie „erfolgreich“ waren, lief kein Rollback. Eine Hintergrundprüfung markierte sie einige Minuten später als fehlgeschlagen, und die gesamte Seite ging auf 404. Der Health-Check zählte Abstürze in der Ereignisliste der Hosting-Plattform. Diese Liste hält aber nur die letzten fünf Ereignisse pro Maschine. Eine Absturzschleife füllt sie, und die Zahl wächst nie weiter. Jetzt vergleicht der Check stattdessen den Zeitpunkt des neuesten Absturzes. Ein Publish in einer Absturzschleife schlägt fehl und stellt die vorherige Version wieder her.

Worauf ein Publish wartet

Wenn du eine App mit Backend auf Mythex veröffentlichst, wird die neue Version auf Maschinen unserer Hosting-Plattform ausgerollt, und ein Health-Check entscheidet, ob der Publish live geht oder fehlschlägt. Bei einem Fehler stellt ein Rollback die vorherige Version wieder her.

Das Schwierige ist, dass „gestartet“ nicht dasselbe ist wie „bedient Anfragen“. Die Plattform meldet eine Maschine als gestartet, sobald sie läuft. Eine App, die eine Sekunde nach dem Start abstürzt, wird sofort neu gestartet, und einen Moment später gilt sie wieder als gestartet. Der Health-Check hatte deshalb im Laufe der Zeit ein paar Schichten bekommen:

1. Zweimal hinschauen. Nachdem eine Maschine als gestartet gilt, wartet der Check kurz und schaut erneut. Ein Absturz beim Start fällt beim zweiten Blick oft auf.
2. Auf Absturzschleifen achten. Meldet die Plattform, dass eine Maschine wiederholt abstürzte und sie das Neustarten aufgegeben hat, schlägt der Publish fehl.
3. Abstürze seit Beginn des Publishs zählen. Zwei „gestartet“-Blicke können einen Neustart überspannen. Gab es seit Beginn des Publishs einen Absturz, schaut der Check ein drittes Mal. Gibt es mehr Abstürze als beim vorherigen Blick, bleibt die App nicht stabil.

Die dritte Prüfung ist diejenige, die hier versagte.

Warum die Zahl gleich blieb

Die Absturzinformationen stammen aus der Ereignisliste jeder Maschine: Starts, Beendigungen, Neustarts. Die Plattform behält pro Maschine nur die letzten fünf Ereignisse.

Stell dir eine App vor, die 2,5 Sekunden nach jedem Start abstürzt, wie eine der drei. Jeder Zyklus fügt einen Absturz und einen Start hinzu. Nach ein paar Zyklen ist die Liste voll. Von da an verdrängt jedes neue Ereignis ein altes. Die Liste schiebt sich weiter, enthält aber immer ungefähr dieselbe Mischung: ein paar Abstürze, ein paar Starts.

„Wie viele Abstürze seit Beginn des Publishs“ lieferte deshalb bei jedem Blick dieselbe Zahl. Der zweite Blick sah etwa zwei Abstürze. Der dritte Blick sah ebenfalls zwei, andere Abstürze zwar, aber dieselbe Anzahl. Der Check schloss daraus, dass das Abstürzen aufgehört hatte, und ließ den Publish durch.

Das passierte am 25. September dreimal, über zwei Apps verteilt. Jedes Mal:

• wurde der Publish als live markiert,
• lief kein Rollback, weil nichts fehlgeschlagen war,
• markierte unser Abgleicher, ein Hintergrundjob, der Deployments nachträglich prüft, das Deployment einige Minuten später als fehlgeschlagen,
• und die ganze Seite gab 404 zurück.

Ein Publish, der rechtzeitig fehlschlägt, lässt sich beheben: Das Rollback stellt die vorherige Version wieder her. Ein Publish, der einige Minuten zu spät fehlschlägt, nachdem er als Erfolg gemeldet wurde, hat sein Rollback bereits übersprungen.

Wie wir es gefunden haben

Wir haben es lokal nachgestellt: eine funktionierende API genommen, sie schlafen gelegt und dann mit einer Änderung neu veröffentlicht, die beim Start abstürzt. Der Health-Check hat sie als live markiert.

Das entsprach der Produktion: Bei jedem der drei Publishes starb die App wenige Sekunden nach jedem Start, und die Absturzzahl, die der Check verglich, stieg zwischen den Blicken nie.

Die Lösung: das neueste Absturzdatum vergleichen, nicht die Anzahl

Statt Abstürze zu zählen, schaut der Check jetzt auf den Zeitpunkt des jüngsten Absturzes seit Beginn des Publishs.

Zeigt der zweite Blick einen Absturz seit Beginn des Publishs, wartet der Check und schaut ein drittes Mal. Ist der neueste Absturz beim dritten Blick später als der neueste beim zweiten, ist die Maschine zwischendurch erneut abgestürzt. Sie bleibt nicht stabil, und der Publish schlägt mit der Meldung fehl, dass die Maschine seit dem Publizieren wiederholt abstürzte und weiterhin neu startet.

Das funktioniert unabhängig davon, wie kurz die Ereignisliste ist. Ein gleitendes Fenster aus fünf Ereignissen kann verbergen, wie viele Abstürze es gab, aber nicht, dass gerade ein neuer passiert ist. Das neueste Ereignis wird immer behalten.

Mit dieser Änderung verhält sich die lokale Nachstellung korrekt: Der Publish schlägt fehl, und die vorherige Version wird wiederhergestellt. Außerdem gibt es einen Test, der das Verhalten der Plattform nachbildet. Bei jedem Blick kommt ein Absturz und ein Start hinzu, und die Liste wird auf fünf gekürzt. Er prüft, dass das Urteil ein Fehlschlag ist und kein Erfolg.

Was wir daraus gelernt haben

• Kenne die Form der Daten, die du zählst. Eine Zählung über eine begrenzte Liste bedeutet nichts mehr, sobald die Liste voll ist. Die Begrenzung war nicht versteckt, wir hatten die Prüfung nur nicht darauf ausgelegt.
• Frag „ist etwas Neues passiert?“ statt „wie viele sind passiert?“. Der neueste Zeitstempel übersteht das Kürzen, eine Summe nicht.
• Ein später Fehlschlag ist schlimmer als ein früher. Derselbe kaputte Build ist harmlos, wenn der Publish fehlschlägt und zurückrollt, und er legt eine Seite lahm, wenn er zuerst als Erfolg gilt.
• Reproduziere unter echten Bedingungen. Der Fehler brauchte eine Maschine, die schon oft genug abgestürzt war, um ihre Ereignisliste zu füllen. Ein einzelner schneller Absturz im Test hätte ihn nicht gezeigt.

Diese Korrektur ergänzt eine andere vom selben Tag, die dafür sorgte, dass das Rollback die alte Version wiederherstellt, statt sie zu löschen: ein fehlgeschlagenes Republish löscht nie ein funktionierendes Backend. Wenn deine eigene App beim Publizieren fehlschlägt, weil sie beim Start abstürzt, sind die Publish-Fehlerbehebung in der Dokumentation und unser Leitfaden zum Debuggen einer mit KI gebauten App gute Anlaufstellen.