Documentation Menu

Async event debugging across queues, callbacks, and webhooks

Asynchronous failures cross service boundaries and time. The producer can succeed while delivery, consumption, processing, or state reconciliation fails later.

Model the event lifecycle

StageEvidence
ProducedEvent ID, producer timestamp, type, and source.
PublishedBroker, webhook provider, or callback delivery record.
ReceivedIngress timestamp, headers, body, and authentication result.
AcceptedDurable inbox or queue message identifier.
ProcessedWorker attempt, result, and side effects.
ReconciledFinal state visible to the user or downstream system.

Correlation fields

  • A stable event ID generated once and propagated unchanged.
  • Trace or correlation ID for each delivery and processing attempt.
  • Causation ID linking a derived event to its parent.
  • Tenant or account ID for scoped investigation.
  • Attempt number and next retry time.

Debugging procedure

  1. Choose one missing or incorrect outcome and identify its expected event.
  2. Find the event at the producer and record its stable identifier.
  3. Follow that identifier through delivery, ingress, queue, worker, and data-store records.
  4. Locate the first stage with missing evidence or a contradictory state.
  5. Check retries, dead-letter handling, ordering, and idempotency at that boundary.
  6. Replay or republish only after confirming the consumer is safe for repeated input.
  7. Verify the final state and add an alert for the detected gap.

Common async failure modes

  • A callback receives 2xx but the durable handoff never occurs.
  • A queue message is processed twice.
  • Events arrive out of order and overwrite newer state.
  • A poison message retries indefinitely without a dead-letter path.
  • A schema changes independently between producer and consumer.
  • A worker succeeds, but reconciliation or notification fails.

How Hookmetry fits

For HTTP callbacks and webhooks, Hookmetry records the receive-side evidence and validation path. Use the event ID to connect that record with queues, workers, traces, and data stores.

Was this page helpful?

Your feedback helps us improve the docs.