Jede Anfrage endet mit einem leeren 500

• Werkzeuge

Dienstag, 10. November 2026 - Matt

Eines Nachmittags beantwortete Whipyard jeden asynchronen Auftrag mit einem HTTP 500. Ohne Text, ohne Problembeschreibung, einfach leer. Synchrone Anfragen liefen noch.

Die Ursache war banal: Die Platte war voll. Asynchrone Ergebnisse bleiben gespeichert, bis der Client sie abholt, sicherheitshalber sieben Tage lang. Bei Texten ist das egal. WhipRadio holt aber Songs und Sprachaufnahmen ab, oft über 130 MB pro Ergebnis. Das waren 42 GB in zwei Tagen. Schlimmer: Die Schleife, die abgelaufene Ergebnisse löscht, war an einem SQLite-Fehler gestorben und räumte gar nicht mehr auf.

Behoben ist das an vier Stellen:

• Ergebnisse bleiben nur noch einen Tag.
• Die Aufräumschleife fängt Fehler ab und macht weiter.
• Kann ein Auftrag nicht gespeichert werden, kommt 507 Insufficient Storage mit einer lesbaren Problembeschreibung statt eines leeren 500.
• Das Dashboard hat eine Karte für den Plattenplatz, die unter zehn Prozent frei rot wird.

Der Haken an einem Tag: Ein Client, der länger als einen Tag offline ist, findet sein Ergebnis nicht mehr und bekommt ein 410 Gone. Für meine Apps passt das, für einen Nachtlauf über ein langes Wochenende nicht. Warum die Ergebnisse überhaupt gespeichert werden, steht im Beitrag zu Anfragen auf einmal statt nacheinander. Der Status 507 stammt ursprünglich aus WebDAV.