# Retries, replay, and resend

Canonical: https://docs.flowrelay.app/recover/retries-replay-and-resend/
Markdown: https://docs.flowrelay.app/recover/retries-replay-and-resend.md

FlowRelay recovery uses three different ideas. Sender resend starts outside FlowRelay, FlowRelay retry and reconciliation run inside FlowRelay, and replay is a deliberate operator or agent action.

## Choose the right recovery path
FlowRelay separates sender resend, FlowRelay retry or reconciliation, and deliberate replay. Pick the path based on what the receipt proves.


- Situation: FlowRelay rejected the request; Use: Sender resend; Why: FlowRelay does not have a trusted accepted event to replay.
- Situation: FlowRelay accepted the event but setup was not ready; Use: FlowRelay replay after a fix; Why: The retained event can be handed to Shopify Flow after endpoint or workflow readiness is corrected.
- Situation: Processing is not terminal yet; Use: Wait for FlowRelay reconciliation or inspect diagnostics; Why: Automatic duplicate side effects are avoided when processing may already have started.
- Situation: Retention expired or replay is unavailable; Use: Sender resend; Why: FlowRelay no longer has replayable event material.
- Situation: The source system intentionally emits a new business event; Use: Sender resend or new send; Why: That is a new source-owned event, not FlowRelay recovery.

## What FlowRelay retries
FlowRelay may retry queue processing or reconcile accepted events that have not reached a terminal handoff result. FlowRelay does not expose configurable retry schedules or per-endpoint retry policies.


## What the sender owns
The sender owns fresh sends and corrected resends. Use sender resend when FlowRelay rejected the request, the source payload must change, replay expired, or the business event is intentionally new.


## Decision guide
Start with the receipt, then choose the lowest-risk recovery path.
1. Use the receipt to identify whether the sender request was rejected, accepted, delivered, failed, duplicate-suppressed, or unavailable for replay.
2. Ask the external sender to resend only when FlowRelay rejected the request, replay is unavailable, or the source system intentionally needs to send a fresh event.
3. Let FlowRelay retry and scheduled reconciliation handle safe accepted-event processing gaps while retained material is available.
4. Do not look for merchant-configurable retry schedules or retry policy controls in FlowRelay.
5. Use replay only after previewing current endpoint configuration, Shopify Flow readiness, duplicate side-effect risk, and grant authority.
6. When processing may already have started, prefer manual review, diagnostics, and explicit replay confirmation over automatic retries.

## Handoff Boundary
Delivered means FlowRelay handed the trigger to Shopify Flow. It does not mean downstream Shopify Flow branches, app calls, fulfillment changes, emails, or later systems completed.

## Related
- [Replay an event](https://docs.flowrelay.app/recover/replay.md)
- [Event lifecycle](https://docs.flowrelay.app/operate/event-lifecycle.md)
- [Retention](https://docs.flowrelay.app/operate/retention.md)

## Safety Boundary
Do not include raw payloads, endpoint secrets, auth headers, HMAC values, Shopify tokens, Shopify sessions, database URLs, customer data, merchant incidents, or copied private logs in public examples.