Open Connector
Replay a failed delivery

Replay a failed delivery

Find the receiver failure, confirm durable deduplication, and replay a retained event without repeating completed work.

Replay a delivery after correcting its receiver failure. The replay preserves the original event ID, so a receiver that already admitted the event must acknowledge the duplicate without repeating its downstream effect.

Before you begin

The following conditions must be satisfied:

  • The connection is active and its relevant grant still permits the event.
  • The subscription is enabled and the receiver's signing secret is valid.
  • The event remains within the 7-day transport journal.
  • Your recovery key has deliveries:read, deliveries:write, events:read, and operations:read, or your Console role permits delivery recovery.

Identify and correct the failure

  1. In Organization → Connector → Connections → Connection → Events → Subscription → Deliveries, select the failed event. Record its event ID, delivery ID, attempts, and last result.
  2. In the receiver logs, find the same IDs. For 401, correct timestamp or signature verification. For 413, reduce the receiver limit mismatch. For 503, restore durable inbox storage. For transport failure, inspect DNS, HTTPS, and proxy routing.
  3. In the receiver's inbox or processing ledger, check whether the original event was admitted before its response was lost. Preserve that admission record.
  4. In Subscription, send Test delivery and confirm Delivered plus a durable test entry at the receiver.

If the receiver is healthy but its downstream worker failed, recover that worker using its existing event record. Transport replay does not reverse or repair a completed external transaction.

Replay and confirm admission

  1. In Subscription → Deliveries → Delivery, select Replay and enter a reason. For API recovery, use Replay a delivery.
  2. Follow the returned operation until Succeeded or Failed. In Deliveries, confirm the replay's result and unchanged event ID.
  3. In the receiver, confirm one admitted inbox identity for that event. Inspect the downstream worker's own completion record before declaring its business task complete.

If Connector reports 410 event_expired, run a complete catalog synchronization. If it reports 409 connection_inactive, restore the reviewed connection or obtain fresh approval after revocation; replay cannot bypass the inactive grant.

Recover after a scope reduction

Read the retained event with the recovery principal. Connector applies present authorization, so its data can be redacted or the event can be inaccessible. Reconcile the receiver's stored copies under its retention rules before resuming broader business processing.

Use a fresh permitted snapshot to establish present state. Restoring an earlier receiver payload does not establish permission to use information removed from the active scope.