Aglet

Verify bounded webhook retry behavior

Retry verification must test response policy and effect identity together. Run a temporary failure, invalid event, duplicate after receipt, recovery, and concurrent batch through the receiver. Inspect attempt count, event identity, receipt, queue, and side-effect state across sender and worker paths.

Check whether the outcome improved

  1. Define response dispositions

    Write expected acknowledgement, sender retry, local retry, receipt, and effect for transient, permanent, duplicate, malformed, and successful events. State finite attempts and what remains reviewable after exhaustion. Keep event identity beside each attempt.

  2. Run recovery and burst cases

    Execute one event and a bounded batch with failure, delay, recovery, and duplicate timing. Confirm event identity survives every attempt and a response does not create a local retry wave unintentionally.

  3. Check permanent boundaries

    Return the chosen permanent or transient status for invalid and valid cases. Verify invalid events do not retry forever, recoverable events remain available, and a duplicate after receipt cannot repeat the effect.

What to carry forward

Accept when transient work retries within a finite policy, permanent cases stop, duplicates remain safe, and event identity survives recovery. Keep sender-specific behavior partial when uncontrolled. Record response matrix, timing fixture, and effect counts. Keep the failed event available for review. Keep retry policy tied to observed response.

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