Aglet

Investigate replayed webhook deliveries

Investigation should explain why one repeated event was accepted, rejected, or applied again. Build fresh, repeated, stale, manual-resend, and old-business-time fixtures, then trace freshness and effect claims. Keep a provider retry, network replay, clock skew, and duplicate worker as competing explanations.

Build a useful investigation brief

  1. Build replay fixtures

    Create a fresh event, the same event again, a stale signed event, a new event with an old business timestamp, and two deliveries for one event. Record expected identity, freshness, and side-effect state before execution.

  2. Trace freshness and claims

    Capture signed timestamp, receiver time, tolerance, event ID, receipt claim, prior result, and handler decision. Compare a repeated event with a legitimate new event. Ensure the delivery ID is not mistaken for the stable event identity.

  3. Vary one repeat condition

    Change only timestamp, clock, event ID, delivery ID, claim timing, or prior effect. Compare safe duplicate acknowledgement with processing. If manual resend and network replay remain indistinguishable, state the missing sender evidence.

What to carry forward

The investigation is ready when fixture traces show identity, freshness, deduplication, and effect decisions for one repeat. Deliver a narrow policy or evidence change. Leave sender retry and manual resend limits explicit when the endpoint cannot distinguish them.

Technical background: Coinbase developer documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow