После сбоя n8n сначала проверьте, появилась ли заявка в CRM, и только потом выбирайте способ повтора. Таймаут означает, что ответ не получен вовремя: принимающий сервис мог уже сохранить запись. Для защиты от дублей одной кнопки повторного запуска недостаточно. Сценарий должен узнавать ту же операцию и проверять её результат.
Ниже лист проверки для руководителя и исполнителя автоматизации. Учебные номера и ожидаемые результаты придуманы для приёмки; это не отчёт об испытании работающего сценария. Проверка документации проведена 24 октября 2026 года (UTC+5).
Что именно вы собираетесь повторить?
В n8n различайте повтор неудачного узла и новый прогон с прежними данными. Узел здесь означает отдельный шаг сценария: например, создание заявки или отправку сообщения. Если знакомитесь с инструментом впервые, начните с разбора что такое n8n и кто обслуживает сценарии.
По документации о повторах, Retry execution продолжает выполнение из сохранённого состояния. Результаты завершённых узлов сохраняются, но неудачный узел получает прежний вход целиком. Если он успел обработать часть записей, они могут попасть в обработку снова. Для Execute Sub-workflow повтор затрагивает весь вызванный подсценарий.
Поэтому сбой сообщения после успешной записи в CRM и сбой самого узла CRM требуют разных проверок. В первом случае не нужно заново создавать заявку ради уведомления. Во втором сначала выясните, какие записи узел уже успел создать. Если повтор тоже завершился ошибкой, не запускайте одновременно повтор исходного выполнения и повтор его неудачной попытки.
Отдельный путь, Copy to editor или Debug in editor, переносит сохранённые данные в текущую схему. Это подготовка к новому прогону, а не обещание безопасного продолжения. Наличие такого режима зависит от варианта установки и доступных функций. Исполнителю нужно показать, какие узлы будут выполнены в вашей версии.
Как проверить заявку после таймаута?
Откройте одно проблемное выполнение и зафиксируйте номер входного события, время, упавший узел и его входные данные. Затем найдите результат в принимающем сервисе. Ищите по устойчивому номеру операции из источника, если он передаётся в CRM. Совпадение имени или телефона само по себе недостаточно: один клиент может оставить несколько самостоятельных заявок.
| Что удалось установить | Следующее действие |
|---|---|
| Запись найдена, её номер и поля соответствуют операции | Сохранить номер записи; восстановить только недостающие действия |
| Записи нет, проверка принимающего сервиса это подтвердила | Устранить причину сбоя и выполнить согласованный безопасный повтор |
| CRM недоступна или результат нельзя уверенно связать с событием | Отметить состояние как неизвестное; передать на разбор, не создавать запись вслепую |
Это предлагаемый порядок разбора, а не встроенная функция любой CRM. Уточните у исполнителя, где искать исходный номер и как сервис показывает результат записи. Пока доказательств нет, сообщение «заявка не создана» будет предположением.
Для исправления уже накопленных записей нужен другой порядок: проверка истории, полей и принадлежности клиентов. Он разобран в статье про дубли клиентов в CRM. Повтор операции и объединение карточек решают разные задачи.
По какому номеру сценарий узнает повтор?
Согласуйте, что компания считает одной операцией. Например, создание заявки по событию формы F-104. Повторная доставка F-104 должна ссылаться на ту же операцию, а новое событие F-105 должно пройти отдельно, даже если текст совпадает.
Для создания заявки и отправки уведомления нужны раздельные отметки результата. Иначе общая запись «обработано» после сохранения в CRM может помешать восстановить неотправленное сообщение. Обратная ошибка тоже возможна: повтор уведомления заново создаст заявку.
В разборе идемпотентности n8n объясняется принцип: принимающая сторона узнаёт повтор операции по ключу и не выполняет действие заново. Один номер выполнения n8n для этого ненадёжен между прогонами: при повторном запуске он меняется. Ключ связывают с исходной операцией, например с номером заказа и видом действия.
Попросите исполнителя подтвердить механизм на стороне конкретного сервиса: поддерживает ли он такой ключ, как долго хранит его и что произойдёт при изменении данных. Добавление заголовка Idempotency-Key само по себе не делает произвольный API безопасным.
Если защита построена на поиске «есть ли уже запись», проверьте одновременные запросы. Два запуска могут оба не найти заявку и затем оба её создать. Нужен механизм, который исключит вторую запись и при таком совпадении во времени: например, ограничение уникальности в хранилище или поддержка повтора принимающим сервисом. Реализацию выбирает исполнитель под вашу систему.
Почему Remove Duplicates не закрывает всю проверку?
У узла Remove Duplicates есть разные режимы: убрать повторы внутри текущего входа или сравнить значения с предыдущими выполнениями. Первый режим не заменяет второй. Для сопоставления между выполнениями можно выбрать уникальный номер либо сочетание полей.
Но отметка «узел уже видел F-104» не доказывает, что CRM сохранила заявку. Если фильтр отбросит повтор после неудачной записи, заявка потеряется вместо того, чтобы задвоиться. У исполнителя должен быть отдельный ответ на вопрос, как восстанавливаются незавершённые операции.
История сравнения ограничена настройкой History Size; предусмотрена и её очистка. Поэтому проверьте повтор после согласованного срока хранения и после обслуживания истории. Не очищайте рабочую историю ради упражнения. Для испытаний нужна отдельная среда с искусственными данными. Само наличие Remove Duplicates в схеме не подтверждает сохранность заявок или защиту при одновременных запусках.
Какие испытания попросить у исполнителя?
Возьмите тестовую CRM или отдельное согласованное место для учебных записей. Отключите отправку настоящим клиентам. До запуска запишите ожидаемый результат каждого случая. Сбои и задержки должен воспроизводить исполнитель в безопасной среде, без отключения рабочего сервиса. До начала испытаний зафиксируйте подтверждённую версию n8n и проверьте доступность нужных функций конкретного сервиса.
Следующую таблицу используйте как учебный эталон при приёмке. Номера и ожидаемые результаты в ней предложены для проверки, а не получены в испытании работающего сценария.
| Учебное условие | Что должно быть подтверждено |
|---|---|
| F-104 доставлено дважды с тем же номером | Одна заявка, обе попытки связаны с её номером |
| F-105 содержит тот же текст, но это новая заявка | Новая операция сохранена отдельно |
| CRM сохранила F-106, но ответ потерян | Повтор не создаёт вторую запись; исходная запись найдена |
| Запись F-107 действительно не состоялась | После устранения причины заявка создаётся, а не отбрасывается как уже обработанная |
| Заявка F-108 создана, уведомление не отправилось | Восстанавливается уведомление, заявка остаётся одна |
| Два запуска одновременно обрабатывают F-109 | В CRM остаётся одна запись; проверка не ограничена последовательными повторами |
Для каждого случая сохраните входной номер, номера выполнений n8n, номер записи в CRM, фактические поля и результат уведомления. Если часть сведений недоступна, отметьте состояние как неизвестное и отдельно укажите, что именно не проверено. Зелёный статус выполнения не заменяет чтение результата в CRM.
Этот набор проверяет конкретные условия, но не доказывает надёжность на любой нагрузке. Дополните его вашим сроком повторной доставки и правилами изменения заявки. Например, новую редакцию заказа нельзя молча отбросить как повтор старых данных.
Что должно остаться после приёмки?
Попросите короткую инструкцию восстановления: где открыть ошибку, по какому номеру искать запись, какой способ повтора допустим и кто разбирает неизвестное состояние. В ней должны быть граница хранения истории, ограничение числа попыток и способ получить сигнал, когда автоматическое восстановление прекратилось.
Согласно документации, повтор доступен только пока выполнение сохранено; настройки могут отключать сохранение неудачных производственных запусков. Поэтому проверьте наличие нужной истории заранее. Отдельно согласуйте хранение подтверждений операций, если для них требуется более долгий срок.
Результат приёмки формулируйте предметно: «Для F-106 запись найдена, после повтора второй записи нет». Если подрядчик показывает только схему с фильтром и кнопку Retry, испытание результата ещё не закончено.