Aglet

Investigate webhook acknowledgement timing

Investigation should show whether the sender retried because the receiver was slow, because receipt was lost, or because response handling was wrong. Build fast, slow, interrupted, and retry-after-receipt fixtures, then trace one event identity through each stage. Keep response latency separate from processing time.

Build a useful investigation brief

  1. Build timing fixtures

    Create fast success, slow downstream, delayed storage, timeout before receipt, receipt then crash, and retry after receipt cases. Record expected acknowledgement, recovery, and side-effect state before execution. Preserve event and delivery IDs in the timeline.

  2. Trace the acknowledgement boundary

    Capture arrival, signature check, receipt write, response status, response time, process interruption, worker start, and completion. Compare the first point where a retry becomes possible. Keep event and delivery IDs distinct.

  3. Vary work placement

    Move only verification, storage, downstream call, queue handoff, or response timing in separate runs. Compare loss and duplicate outcomes. If sender timeout rules are unknown, state the missing evidence rather than assign a fixed limit.

What to carry forward

The investigation is ready when timing fixtures show receipt, response, retry, and side-effect transitions for one event. Deliver a durable handoff or timing change with bounded tests. Keep sender-specific timeout behavior explicit. Keep sender retry behavior as an external evidence boundary.

Technical background: Stripe 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