A dispatch snapshot is the transformed payload at the moment of dispatch — the bytes the relay actually sent to the destination. Hooksbase persists a dispatch snapshot per delivery, separately from the raw payload.
Why two persisted payloads instead of one?
The naive approach is to persist only the raw payload and re-transform on replay. This breaks the moment you change the transform config: replays of past failures produce different output than the original delivery.
The discipline that makes deterministic replay work:
- Raw payload persisted in R2, keyed by delivery ID
- Dispatch snapshot persisted in R2 separately, also keyed by delivery ID
- Replay uses the dispatch snapshot, not the raw payload + current transform
This means a transform change today doesn't break replays of retained deliveries from yesterday. The original transform is captured in the snapshot; replays use what was actually sent.
How this maps to recovery
Two failure-recovery scenarios make the distinction concrete:
- The destination had a bug; you fixed it. Replay the dispatch snapshot — the destination receives the same payload it should have processed correctly the first time.
- The transform itself was wrong. Replay preserves the original transformed snapshot, so a transform fix does not rewrite old replay payloads. Use a source-system backfill or fresh ingest when you need the new transform to apply.
That constraint is intentional: replay is for reproducing the exact delivery input, not for silently changing historical events.
For the deeper read: Deterministic replay for agents.
Related terms
- Replay
Re-running a retained event with the same input — typically after fixing a bug that caused the original to fail.
Read - Payload
The body of an HTTP request — for webhooks, almost always JSON.
Read - Webhook
An HTTP request one service sends to another to notify it that something happened.
Read - Attempt
One HTTP request within a delivery's retry chain.
Read