Обработка ошибок в n8n: ретраи, error workflow и надёжная автоматизация

Воркфлоу, собранный за вечер, работает. Воркфлоу, который работает через полгода без вашего внимания, - это другой инженерный объект. Разница между ними почти целиком в обработке ошибок.

Главная опасность - тихий отказ

Автоматизация редко ломается громко. Обычно происходит одно из двух: воркфлоу деактивируется после серии падений и просто перестаёт запускаться, или он отрабатывает вхолостую - триггер сработал, данные не пришли, ноль результата, ошибки нет.

Оба случая объединяет одно: никто не узнает. Данные не текут, бизнес-процесс стоит, а обнаруживается это через неделю и обычно снаружи - от клиента или бухгалтера.

Поэтому первое, что нужно сделать в продакшене, - не улучшить логику, а сделать отказ заметным.

Error workflow

n8n позволяет назначить воркфлоу, который запускается автоматически при падении другого. Он получает данные о том, что упало, где и с какой ошибкой.

Это самая дешёвая надёжность из доступных: один воркфлоу с уведомлением, привязанный ко всем боевым автоматизациям. Минимально полезное сообщение содержит имя воркфлоу, ноду и текст ошибки - иначе вы получаете «что-то сломалось» и всё равно идёте разбираться вручную.

Ограничение, которое стоит понимать: error workflow ловит падения, но не ловит пустые результаты. Воркфлоу, который отработал и ничего не сделал, формально успешен. Для таких случаев нужна отдельная проверка - например, ежедневный контроль «сколько записей обработано» с сигналом, если ноль.

Настройки на уровне ноды

У каждой ноды есть параметры поведения при ошибке. Три, которые реально используются:

Повтор при ошибке. Число попыток и пауза между ними. Закрывает большую часть внешних сбоев: сеть моргнула, сервис отдал 502, ответ пришёл дольше обычного.

Продолжить при ошибке. Нода не роняет выполнение, а передаёт ошибку дальше, и вы обрабатываете её как данные. Полезно при пакетной обработке: одна плохая запись из ста не должна останавливать остальные 99.

Таймаут. Ограничение на время ответа. Без него медленный API держит выполнение неопределённо долго - а при частом расписании это ещё и накопление параллельных запусков.

Что повторять, а что нет

Разделение простое и почти всегда одинаковое.

Повторять имеет смысл: сетевые сбои, таймауты, ответы 5xx, превышение лимита частоты (с паузой подлиннее). Это состояния, которые со второй попытки проходят.

Повторять бессмысленно: ошибки авторизации, 404, невалидные данные, исчерпанная квота. Повтор их не исправит - он только потратит время и в случае с лимитами усугубит ситуацию.

Практическое следствие: повтор без ограничения - это скрытый бесконечный цикл. Всегда задавайте предел попыток.

Идемпотентность

Ретраи и повторные запуски порождают вопрос, о котором забывают на этапе сборки: что будет, если этот шаг выполнится дважды?

Для чтения данных ответ «ничего». Для создания заказа, списания денег или отправки письма - совсем другой. Воркфлоу, который при повторе создаёт вторую копию записи, опаснее воркфлоу, который просто упал.

Защита сводится к тому, чтобы действие можно было безопасно повторить: проверять существование записи перед созданием, использовать идентификатор операции, который сервис распознаёт как дубль, или помечать обработанные элементы в своей базе.

Это не теория: при любых ретраях и при ручном перезапуске упавшего выполнения повтор происходит регулярно.

Частичная обработка

Отдельная неприятность: выполнение упало посередине - половина элементов обработана, половина нет. Перезапуск с начала обработает первую половину повторно.

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

Минимум для продакшена

Перед тем как автоматизация станет частью рабочего процесса:

1. Error workflow с уведомлением привязан ко всем боевым воркфлоу.
2. Ретраи настроены там, где ошибки временные.
3. Таймауты проставлены на внешних вызовах.
4. Повторное выполнение безопасно для всего, что создаёт или отправляет.
5. Есть сигнал о пустом результате, а не только о падении.

Пятый пункт пропускают чаще всего - и именно он ловит самые дорогие отказы.