Workflow n8n упал после создания задачи в CRM, и повтор плодит дубли. Разбираем атомарный claim, ключ события и сверку перед retry.
В сообществе n8n сошлись несколько обсуждений об одном и том же сбое. Workflow рапортует об ошибке, хотя действие во внешней системе уже выполнено, а повторный запуск создаёт вторую задачу в CRM. Повтор безопасен, когда он знает, что уже произошло. Без этого знания остальные меры надёжности (алерты, ретраи, мониторинг) не спасают от дубля.
Автор одного из демо описывает ситуацию так.
Обращение клиента доходит до CRM, но ответ от CRM назад не приходит. Workflow помечается как упавший.
Команде нужно выяснить, существует ли follow-up, прежде чем запускать процесс снова.
Если ошибиться, последствия два: клиент потерян или ему звонят два менеджера с одним и тем же вопросом. В демо автор намеренно теряет ответ после создания задачи.
Оператор получает действие восстановления, которое находит уже существующую задачу.
Исходную доставку затем проигрывают повторно, и результат остаётся прежним: одна задача, назначенная на Sales.
Граница здесь проходит так: ошибка случилась уже после побочного эффекта, а выполнение считается неуспешным. Схема «упало, значит, запустим заново»
в этой точке создаёт дубль.
Другой участник обсуждения разобрал, как собрать защиту в n8n, и порядок у него такой.
Сначала вычисляется стабильный ключ события: хеш от источника и внешнего идентификатора события (`source + externalEventId`). Ключ нормализуют: нижний регистр, обрезанные пробелы, канонический часовой пояс во всех временных метках.
Затем Postgres-нода выполняет `INSERT INTO event_claims(event_key, status, claimed_at) VALUES (...) ON CONFLICT DO NOTHING RETURNING event_key`.
Если результат пустой, событие уже заявлено другим выполнением, и текущее выполнение действие не запускает. Атомарность обеспечивает база данных: два параллельных выполнения не могут одновременно вставить одну и ту же строку. Отдельный запрос «а не было ли такого события?» перед вставкой такой гарантии не даёт: между проверкой и записью другое выполнение успевает проскочить. Нормализация ключа тоже важна.
Один и тот же адрес в разном регистре или одна и та же временная метка в разных зонах дают два разных хеша, и защита молча перестаёт работать.
Участники обсуждения сошлись на том, что больнее всего бьёт прерывание после успешного внешнего действия, но до записи о завершении. Claim уже стоит, статус остаётся «в работе», а задача в CRM уже создана. Claim фиксирует только намерение выполнить действие, а о его результате ничего не сообщает.
Поэтому перед повтором нужна сверка с внешней системой: найти задачу по ключу события и, если она есть, закрыть запись как выполненную.
Именно это делает «recovery» в демо.
Объединение двух подходов в одну схему - наша интерпретация: каждый автор описывает только часть.
Для CRM, где задачу можно искать по внешнему идентификатору, схема работает прямо.
Если система такого поиска не даёт, схему придётся дополнить, например записывать ключ события в поле задачи при создании.
Дубль задачи в CRM выглядит мелочью, пока он не превращается в два звонка клиенту, двойной счёт или двойное списание.
Цену ошибки задаёт то, что находится за побочным эффектом: деньги, клиент, репутация. Сам n8n на неё не влияет. Есть и рыночный сигнал.
Те же ветки форума заполнены объявлениями фрилансеров, которые предлагают дедупликацию, обработку ошибок и follow-up-сценарии как отдельную услугу.
Спрос существует, потому что без этих механизмов автоматизация выглядит рабочей до первого сетевого сбоя.
Патч n8n 1.123.83 закрепляет версию `cjs-module-lexer` 2.2.0 по итогам ревью.
Это обычное обслуживание платформы, к идемпотентности оно отношения не имеет.
Платформа обновляется регулярно, а корректность повтора обеспечивает тот, кто проектирует процесс.
В [AI-native integration](/) мы закладываем идемпотентность на старте, потому что на ней держится время до результата (TTU).
Простая на вид схема «заявка пришла, задача создана»
требует стабильных ключей событий, таблицы заявленных событий, сверки с внешней системой и понятного экрана оператора.
Тот же принцип действует на другом масштабе: консьюмер Apache Kafka с семантикой «минимум один раз» или шина уровня MuleSoft дают дубли по построению, и дедупликация по ключу события там обязательна.
Ещё одно практическое правило пришло из соседнего обсуждения.
Его автор советовал разбить один большой workflow на три маленьких: онбординг, ежедневный план и приём входящих сообщений.
Для повторов это окупается вдвойне: границу «до побочного эффекта»
и «после» проще тестировать и чинить в небольшом сценарии.
Прежде чем добавлять в workflow ещё одну ветку с ИИ, проверьте одно: что произойдёт, если оборвать выполнение сразу после успешного вызова внешней системы? Если ответ «не знаем» или «получится дубль», автоматизация не готова к продакшену, и нагружать её новыми возможностями рано. Руководитель засчитывает результат тому процессу, который переживает собственный сбой.
