When an n8n API timeout may already have committed

说明与用途

在 n8n 中，HTTP 请求可能在远程系统已接受后超时，导致重复操作。解决方案是在第一次尝试前生成稳定的操作键，持久化状态，使用幂等性键，并在超时后进行对账。

问题

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.

来源