Workflow n8n отработал дважды, и никто не заметил

На форуме n8n разобрали самый неприятный класс ошибок автоматизации: workflow запускается дважды и оба раза выполняет один и тот же побочный эффект.

Клиент получает два приветственных письма, со счёта списывают оплату повторно, лид трижды попадает в CRM.

Главная мысль разбора: без идемпотентности результат автоматизации зависит от удачи, а о дубле вы узнаёте, когда логи исполнения уже удалены.

Первичный разбор: Your n8n workflow runs twice and nobody notices: idempotency patterns that fix it, сообщество n8n.

Упавший workflow виден сразу: красный статус, алерт, разбор. Дубль выглядит как успех.

Оба запуска завершились зелёными, а метрика «обработано заявок» выросла.

Автор разбора отмечает, что о проблеме узнают через недели, по жалобе клиента или по расхождению в бухгалтерии. К этому моменту истории выполнений нет, и определить, какой из запусков был лишним, нечем.

Для владельца бизнеса это деньги и репутация.

Двойное списание превращается в возврат, извинения и разбирательство с платёжным провайдером.

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

Источников три, и все штатные. Retry On Fail.

Узел обращается к внешнему API, получает таймаут и повторяет запрос.

Таймаут означает лишь то, что ответ не пришёл, а сам запрос мог уже выполниться на стороне получателя.

Повтор отправляет его снова. Повторная доставка webhook.

Платёжные и e-commerce-провайдеры, включая Stripe, повторяют доставку события, если не получили быстрый ответ 2xx.

Пока workflow обрабатывает событие, провайдер успевает отправить его второй раз. Ручной перезапуск.

Оператор видит ошибку в середине цепочки и запускает всё с начала.

Шаги, которые уже отработали, выполняются заново. Общий корень у всех трёх: доставка гарантируется «как минимум один раз».

Гарантию «ровно один раз» строит разработчик на своей стороне.

а, например id события провайдера, или собираем его из бизнес-полей: номер заказа плюс тип действия.

Время запуска в ключ не годится, у каждого повтора оно своё. - Хранилище обработанных ключей.

Таблица в базе с уникальным индексом по ключу.

Вставка нового ключа проходит, вставка существующего падает, и workflow завершается без действия.

Проверка «есть ли запись» с вставкой отдельным шагом оставляет окно гонки, поэтому уникальный индекс надёжнее. - Идемпотентные операции вместо вставок. Upsert по внешнему id в CRM вместо create: повторный вызов приводит запись к тому же состоянию. - Ключ идемпотентности в вызове API.

Если внешний сервис принимает такой заголовок, передаём его, и повтор вернёт результат первого вызова. - Быстрый ответ webhook.

Принять событие, положить в очередь, ответить 200.

Тяжёлая обработка идёт после ответа, и у провайдера нет причин повторять доставку.

Ничего из этого не выглядит эффектно, поэтому в демонстрациях такого не показывают.

В релизах n8n 2.42.6 и 2.43.3 платформа начала блокировать создание и обновление workflow с устаревшими (deprecated) узлами.

Разработчики n8n закрыли один класс тихих проблем на уровне платформы.

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

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

Вывод тот же: границы гарантий автоматизации нужно записывать заранее.

На форуме полно объявлений вида «строю AI-автоматизации, экономлю время»

: n8n, агенты, RAG, генератор ответов на письма, обогащение лидов.

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

Время до результата, которому можно доверить деньги, определяют другие вопросы: что будет на сотом дубле, при таймауте провайдера в пятницу вечером, при ручном перезапуске. В интеграционных проектах KT.Team, будь то связка 1С с витриной, обмен с PIM вроде Pimcore или Akeneo или очереди на Apache Kafka, идемпотентность закладывается в контракт обмена до первой строки кода.

Для событий на Kafka это ключ сообщения и таблица обработанных смещений.

Для AI-агентов в n8n это ключ задачи, по которому повторный запуск возвращает прежний результат.

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

За ним стоит тяжёлая инженерная работа, которую не видно, пока она сделана хорошо.

Первичный разбор: «Your n8n workflow runs twice and nobody notices: idempotency patterns that fix it»

, сообщество n8n, https://community.n8n.io/t/your-n8n-workflow-runs-twice-and-nobody-notices-idempotency-patterns-that-fix-it/320198.

Изменения платформы: релизы n8n 2.42.6 и 2.43.3 на GitHub (n8n-io/n8n).

Лицензия материалов форума: условия сообщества n8n.

Выводы и примеры по Kafka и интеграциям принадлежат редакции KT.Team.