Від [object Object] до правила ESLint: як агентна автоматизація GitHub знайшла і локалізувала клас помилок

Невдале повідомлення [object Object] здається дрібницею, поки його не бачить користувач замість реальної причини збою. У GitHub Agentic Workflows такий випадок знайшов не ручний bug report, а щоденний Safe Outputs Conformance Checker. Історія показує корисний для будь-якої команди цикл: автоматична перевірка формулює сигнал, інженер уточнює інваріант, тест фіксує очікувану поведінку, а статичний аналіз шукає той самий ризик в інших файлах.

Звідки взялася помилка

Щоденний скрипт check-safe-outputs-conformance.sh перевіряє реалізацію Safe Outputs, групує відхилення за важливістю та ідентифікатором і створює короткоживучі issues для суттєвих випадків. Перевірка MCE-006 шукала, чи серіалізуються помилки MCP у читабельний текст. Спочатку спрацювання здавалося хибним: основний модуль не викликав String(e.message) безпосередньо, а делегував форматування спільному helper.

Але перевірка привела до реального граничного випадку. Якщо код кидав звичайний об’єкт, у якого поле message саме було не рядком, helper міг застосувати String(error) до всього об’єкта. Для структури на кшталт { message: { reason: "x" } } результатом ставав формально валідний, але беззмістовний текст [object Object].

Виправили код і саму перевірку

У точковому PR логіку зробили явною: якщо не-Error об’єкт має поле message, рядкове значення повертається як є, а інше значення перетворюється на текст саме з цього поля. Лише об’єкти без message використовують fallback для цілого значення. До тестів додали числові та складені повідомлення, тому граничний випадок тепер є частиною контракту.

Водночас команда не просто «підкрутила regex», щоб зелений CI повернувся. MCE-006 навчили розпізнавати безпечний шлях через getErrorMessage(). Це принципово: хороша conformance-перевірка захищає властивість системи — читабельність помилки — а не вимагає одного конкретного написання коду.

Як з одного дефекту вийшло правило ESLint

Окремий ESLint Miner використав випадок як зерно для вузького правила no-string-fallback-for-non-string-message. Воно шукає форму, де код перевіряє x.message, але у fallback перетворює на рядок весь x, а не x.message. Автоматичне переписування навмисно не ввімкнули: правильне повідомлення залежить від локального контексту, тому правило лише попереджає.

Пошук знайшов чотири живі збіги в setup-діях: модулі запуску workflow, slash-команд, розбору логів і CLI Safe Outputs. Кожен випадок потребує окремого рішення, але клас помилок уже перестав бути невидимим. У результаті один слабкий сигнал перетворився на issue, patch, регресійні тести та інструмент профілактики.

Що варто повторити у власному CI

• Формулюйте conformance checks навколо користувацької властивості, а не конкретного фрагмента коду.
• Після виправлення дефекту шукайте його структурний патерн у всьому репозиторії.
• Для неоднозначних випадків починайте з warning, а не небезпечного autofix.
• Додавайте тести для thrown values, які не є екземплярами Error.
• Робіть автоматично створені issues короткоживучими, щоб новий прогін замінював застарілий шум.

Обмеження

Статичне правило бачить синтаксичну форму, а не повний намір програми. Воно може пропустити інший спосіб зіпсувати повідомлення або підсвітити код, де fallback був свідомим. Тому найбільша цінність підходу — у зв’язці перевірки, тестів і людського review, а не в окремому агенті чи linter.