When an n8n API timeout may already have committed

Описание и применение

В n8n запросы могут завершаться тайм‑аутом после того, как удалённая система уже приняла их, что приводит к двойным операциям. Решение – генерировать стабильный ключ операции до первого запроса, сохранять его и состояние, использовать idempotency‑ключи и выполнять реконсиляцию после тайм‑аутов.

Задача

n8n HTTP Request nodes can fail after the remote system has already accepted the request, leading to ambiguous commits and potential duplicate business actions.

Результат

By persisting a stable operation key and tracking state, the workflow avoids duplicate leads caused by ambiguous timeouts, ensuring idempotent behavior across retries.

Рабочий процесс

• Generate a stable operation key before the first attempt (e.g., "create-lead:" + source_event_id).
• Persist operation key, source event ID, request fingerprint, provider name/endpoint, and state="prepared" before calling the provider.
• Send the request with the idempotency key if supported, or store the key and result in a durable table.
• On success, record provider object ID and mark state="confirmed".
• On definite rejection, record safe-to-retry or terminal result.
• On timeout or ambiguous response, mark state="ambiguous" and do not create a new business operation.
• Reconcile on next run: look up by idempotency key or fingerprint; if provider object exists, mark confirmed; if not, retry with the same operation key; if inconclusive, route to delayed retry or operator review.

Доказательства

For every side-effecting request, generate one stable operation identity before the first attempt and reuse it for every retry.

Источник

On a timeout, broken connection, or malformed response, mark ambiguous. Do not immediately create a new business operation.

Источник