A timeout is not a failed webhook: reconcile before you retry

说明与用途

在 webhook 超时时，无法确定操作是否成功。该方案通过使用键和哈希进行预留、跟踪状态，并与提供商进行对账，以避免重复操作。

问题

When a webhook request times out, it is unclear whether the provider applied the change, risking duplicate effects if retried.

结果

The recipe demonstrates local state transitions that prevent duplicate webhook actions after timeouts, using a reservation table and reconciliation via provider readback.

工作流

• Generate a stable operation key and payload hash for each business operation.
• Persist the key, hash, and a 'dispatching' state in a durable store before calling the remote service.
• If a worker receives the same key, check existing state: if payload differs, treat as conflict; if same, skip sending again.
• After a timeout, mark the operation as 'unknown' and do not enqueue it for automatic retry.
• Reconcile by reading the provider’s state (using provider ID or stable identifier) to verify whether the effect already exists.
• If the effect matches, record the provider reference and mark the operation as 'verified'; otherwise keep it in 'unknown' for manual investigation.
• Only retry operations that are confirmed failures, not those with unknown outcomes.

证据

A webhook request times out. Should the worker retry?

来源

Give each business operation a stable key. Persist that key, the payload hash, and a dispatching state before calling the remote service.

来源

After a timeout that may have occurred after dispatch, retain the operation and mark it unknown. Do not put it back into the normal retry queue.

来源

Look up the original effect using a returned provider ID or a stable identifier that the provider actually supports.

来源