Aglet

Investigate webhook retry status mapping

Investigation should show how a handler branch became a delivery disposition. Build invalid, duplicate, transient, authorization, and success fixtures, then trace response and effect state. Compare the response generated by the handler with the sender’s next attempt before attributing delivery behavior to framework error handling.

Build a useful investigation brief

  1. Build status fixtures

    Create malformed event, duplicate after effect, temporary dependency failure, authorization rejection, handler exception, and success cases. Record expected status, receipt, retry, and effect before execution. Preserve response and receipt metadata.

  2. Trace status production

    Capture validation, handler branch, receipt write, response status and body, sender attempt, and local result. Compare the first difference between intended and actual disposition. Keep event identity stable across attempts.

  3. Vary one failure branch

    Change only validation result, dependency state, exception, receipt timing, or status mapping. Compare retries and effects. If sender behavior cannot be seen, state the missing delivery evidence rather than inferring it from one response.

What to carry forward

The investigation is ready when fixtures connect handler branch to status, receipt, retry, and effect. Deliver a narrow mapping or evidence change. Keep sender-specific retry limits and external history explicit. For each fixture, state whether the sender retried, stopped, or remains unobserved, and whether a durable receipt exists independently of that response.

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