Повторени събития в n8n: как да избегнете двойни записи и изпращания

Защо повторното изпълнение създава двойни действия.

За да избегнете двойни записи и изпращания в n8n, всяко бизнес действие трябва да има стабилен ключ и проверимо състояние. Правото за изпълнение се заявява атомарно, а при повторение се проверява вече постигнатият резултат. Обикновено „провери дали съществува, после създай“ не е достатъчно при паралелни изпълнения.

Webhook може да бъде доставен повторно, API заявка може да изтече по време, а оператор може да пусне отново неуспешен процес. Повторението е нормално поведение на интеграциите. Защитата трябва да е част от свързването на системите с n8n, а не поправка след първия дублиран запис.

Заявете изпълнението атомарно.

При два паралелни процеса и двата могат да проверят „няма запис“ преди който и да е да го създаде. Решението е уникално ограничение и атомарна операция в хранилището, не две отделни проверки в workflow.

Следният PostgreSQL пример показва само първоначалното заявяване на ключ. Той не е готов n8n workflow и сам по себе си не решава възстановяването след срив или външните действия. При реална интеграция стойностите се подават като параметри, без конкатениране на входния текст в SQL.

CREATE TABLE action_claims (
  action_key text PRIMARY KEY,
  state text NOT NULL,
  claimed_at timestamptz NOT NULL DEFAULT now(),
  external_id text
);

INSERT INTO action_claims (action_key, state)
VALUES ($1, 'processing')
ON CONFLICT (action_key) DO NOTHING
RETURNING action_key;

Само изпълнението, което получава върнат ред, е заявило новия ключ. Останалите проверяват състоянието на съществуващото действие. „Няма върнат ред“ не означава непременно „вече е завършено“: първият процес може още да работи или да е спрял.

Документацията на PostgreSQL за INSERT и ON CONFLICT описва тези операции. Уникалният ключ защитава заявяването в базата, но не прави външния API автоматично идемпотентен.

Разгледайте най-трудния случай: действие без получен отговор.

API създава обекта, но отговорът не достига до n8n. Локално няма записано „completed“. Сляпото повторение може да създаде втори обект. Ако API поддържа ключ за идемпотентност, използвайте същия ключ според неговия договор и срок за съхранение.

Ако няма такава поддръжка, използвайте разрешена външна референция за намиране на резултата или преглед на неопределеното състояние. При изпращане на имейл без надежден механизъм за проверка може да остане риск от повторение. Не обещавайте универсално „точно веднъж“ изпълнение между независими системи.

Stripe документира собствен договор за идемпотентни заявки. Това е пример за API механизъм; не предполага, че вашият CRM, TMS или имейл доставчик има същото поведение.