n8n: Error Workflow не запускается после ошибки — как проверить обработчик

Сценарий поддержки получает обращение, передаёт текст AI-агенту и сохраняет результат. Вы добавляете отдельный workflow с Error Trigger, запускаете основной сценарий кнопкой Execute Workflow и намеренно вызываете ошибку. Основной запуск красный, обработчик молчит. Кажется, что сломан триггер или потерялись credentials уведомлений. Но до отправки уведомления выполнение вообще не дошло.

У этой проверки есть важная особенность: Error Trigger срабатывает при ошибке автоматического выполнения. Ручной запуск из редактора для такой проверки не подходит. Поэтому сначала нужно воспроизвести правильный тип запуска, затем проверить связь сценариев и только потом разбирать канал уведомлений.

Отделите доставку ошибки от отправки сообщения

Создайте workflow Support Error Handler. Первым узлом поставьте Error Trigger, вторым — Code. Пока не подключайте почту и мессенджер: пустой канал, недействительный токен и недоступный сервер добавят ещё одну причину сбоя. Сохраните workflow. Сам обработчик с Error Trigger публиковать для срабатывания не требуется.

В настройках основного сценария найдите Error workflow, выберите сохранённый обработчик и сохраните настройку. Наличие Error Trigger в другом workflow само по себе не связывает его с основным. Один обработчик можно назначить нескольким сценариям, поэтому полезно сразу сохранять имя и идентификатор источника.

В Code выберите Run Once for All Items и вставьте следующий код. Он приводит два вида входного события к одной записи: ошибку внутри выполнения и ошибку исходного триггера.

const event = $input.first().json;
const execution = event.execution ?? {};
const error = execution.error ?? event.trigger?.error ?? {};
return [{json: {
  workflowId: String(event.workflow?.id ?? "unknown"),
  workflowName: event.workflow?.name ?? "unnamed",
  executionId: execution.id ?? null,
  executionUrl: execution.url ?? null,
  failedNode: execution.lastNodeExecuted ?? error.node?.name ?? null,
  message: error.message ?? error.cause?.message ?? "Unknown error",
  retryOf: execution.retryOf ?? null
}}];

Ссылка на выполнение полезна в уведомлении, но поле может отсутствовать: например, сбой произошёл в триггере и обычное выполнение ещё не создано. Код сохраняет null, чтобы следующий узел мог выбрать сообщение без ссылки. Иначе вторичная ошибка форматирования замаскирует исходную проблему.

Вызовите автоматическую ошибку в отдельном стенде

Для теста создайте отдельный основной workflow Support Failure Probe: Schedule Trigger → Stop And Error. Задайте расписание на ближайшее удобное время, а в Stop And Error — короткое сообщение support-probe: synthetic failure. Назначьте ему ваш Error workflow. Здесь нет обращения к модели, реальной CRM и клиентским данным, поэтому запуск можно повторять без внешних записей.

Опубликуйте основной тестовый сценарий и дождитесь срабатывания расписания. Откройте Executions основного workflow: нужен запуск от расписания со статусом ошибки. Затем откройте Executions обработчика и найдите событие с именем Support Failure Probe и тем же текстом ошибки. После проверки снимите тестовый сценарий с публикации, чтобы он перестал создавать искусственные инциденты.

Если обработчик появился, механизм доставки исправен. Теперь подключайте канал уведомлений после Code и повторяйте тот же тест. Так два вопроса получают отдельные ответы: пришло ли событие об ошибке и удалось ли доставить сообщение дежурному. Для воспроизведения не нужно заставлять платную модель ошибаться или ждать настоящего отказа API.

Почему реальная ошибка всё равно может пройти мимо

Вернитесь к неудачной заявке и посмотрите итоговый статус execution. Ветка, которая получила ошибку узла и продолжила работу, может завершить workflow успешно. Само наличие объекта error в данных ещё не означает провал всего выполнения. Для бизнес-ситуации «ответ агента нельзя использовать» заранее решите, что должно произойти: отдельная очередь ручной обработки либо остановка через Stop And Error.

Например, модель вернула категорию, отсутствующую в вашем справочнике. Если проверяющая ветка записала заявку в очередь оператора, это может быть ожидаемый успешный исход. Если же сценарий обязан построить корректный ответ и запасного пути нет, завершайте его ошибкой с понятным кодом причины. Тогда централизованный обработчик увидит именно тот исход, ради которого он настроен.

Сохраняйте в уведомлении workflow, узел, идентификатор выполнения и короткую причину. Полное содержимое обращения и stack trace обычно не нужны в общем чате поддержки. Детали лучше открывать в ограниченном интерфейсе execution. При повторе сохраняйте retryOf: он помогает отличить новый инцидент от повторного запуска уже известной ошибки.

Превратите проверку в приёмочный сценарий

Перед переносом workflow повторяйте два случая: автоматическая необработанная ошибка вызывает обработчик; предусмотренный отказ AI переводит заявку в выбранный запасной путь. Сохраняйте идентификаторы обоих запусков. Это даёт конкретное доказательство работы оповещения после смены окружения, credentials или настроек узлов.

В платном курсе «Продвинутый n8n: production-автоматизации и AI-агенты» вы отработаете обработанные и необработанные ошибки, проверку сценариев на fixtures и сбор данных для разбора инцидента, а затем соедините блоки в support pipeline. Откройте программу и выберите модуль ошибок и sub-workflows. Если пока сложно собрать тестовую цепочку, начните с бесплатного приквела по n8n.

После восстановления оповещений отдельно проверьте повтор ошибочного выполнения: получение уведомления ещё не определяет, какие внешние действия безопасно повторить.