The Webhook Timeout Trap: Why My n8n Webhook Stopped Timing Out (Respond First, Work Later)

说明与用途

在 n8n 中立即响应、去重和单独错误处理消除了重复订单和邮件，并停止了发送方的重试。

问题

The sender’s 30‑second timeout caused the n8n webhook to retry, producing duplicate orders and emails while the workflow ran 60–90 seconds.

结果

Fast acknowledgment and idempotent processing eliminated duplicate orders and emails, reduced sender retries to zero, and improved reliability.

工作流

• Webhook Trigger → Respond to Webhook (200, {"received":true,"event_id":"{{ $json.id }}"}) → Dedupe check (skip if event_id seen) → LLM call → Database write → Confirmation email

证据

The workflow validates the order, calls an LLM to generate a fulfillment summary, writes rows to my database, sends confirmation emails. About 60–90 seconds of real work, end to end.

来源

My workflow took 90 seconds to answer. So the sender did exactly what senders do – it retried. Twice. Three "successfully processed" runs, three confirmation emails, three database rows for the same order.

来源

The webhook’s only job is to acknowledge receipt; the real work happens after the response.

来源

Responding fast is only half the fix. It creates two obligations: 1. Idempotency is now mandatory, not optional. 2. You need to know when background work fails.

来源