Что и где ломается

Сценарий, который безотказно работает на тестовых данных, — это иллюзия. В продакшене он рано или поздно столкнётся с ошибкой. Прежде чем учиться их обрабатывать, полезно понять, где именно обычно всё ломается.

Примечание. Конкретные кнопки и опции, связанные с обработкой ошибок, в n8n со временем перемещаются и переименовываются. Принципы, описанные в этой главе, остаются прежними.

Внешние сервисы недоступны

Самый частый источник проблем — внешние API. Они могут:

  • временно лежать (5xx ошибки);
  • возвращать ошибку 429 (rate limit), если вы слишком часто к ним обращаетесь;
  • отвечать слишком долго и вызывать таймаут;
  • возвращать неожиданный формат данных после обновления на их стороне.

Если ваш сценарий обращается к стороннему API, считайте, что он обязательно упадёт хотя бы иногда — просто не из-за вас.

Изменения в данных

Поля в API-ответе появляются и исчезают. Поле, которое вчера называлось email, сегодня может называться emailAddress. Поле, которое было обязательным, может стать опциональным — и в каком-то item его не окажется.

Все выражения вида {{ $json.user.address.city }} на таких данных дают исключение. Сценарий упадёт.

Авторизация

Учётные данные истекают. Токены OAuth перестают быть валидными, API-ключи отзываются, пароли меняют. Сценарий, который месяцами работал, в один момент начинает получать 401 / 403.

Ограничения и квоты

Внешний сервис может ввести новые ограничения, понизить лимиты, начать брать деньги. Сценарий формально работает, но запросы отклоняются.

Ошибки в логике сценария

Самое неприятное — ошибки, в которых виноват не внешний мир, а сам сценарий: неправильное выражение, лишний цикл, гонка между параллельными узлами, неправильная обработка пустых items. Они проявляются не сразу и часто только на «странных» данных.

Webhook-ошибки

Если у вас есть webhook, его могут начать дёргать боты, сканеры, кривой клиент. Ваш сценарий должен корректно реагировать на:

  • запросы без обязательных полей;
  • запросы с мусорным телом;
  • одинаковые повторы (idempotency);
  • слишком большие payload'ы.

Что делать

Из этого следуют простые принципы:

  1. Считайте, что ошибки будут. Не «если», а «когда».
  2. Решайте на стадии проектирования, что произойдёт при каждом сбое. «Игнорируем», «повторяем», «пишем в лог», «уведомляем человека» — это разные ответы.
  3. Никогда не оставляйте критичный сценарий без уведомлений о сбоях. Если вам никто не скажет, что сценарий упал, вы узнаете об этом от пользователя — и это плохой сценарий.

Дальше в главе мы разберём конкретные механизмы: retry, continue on fail, error trigger workflows, уведомления.