Retries, replay, and resend

# 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.


## Manual review
Manual review means FlowRelay paused automatic recovery because Shopify Flow may already have received the handoff, so a duplicate Shopify Flow action could run. Use diagnostics and the replay preview before approving any second handoff.


## 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.
- Use the receipt to identify whether the sender request was rejected, accepted, delivered, failed, duplicate-suppressed, or unavailable for replay.
- 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.
- Let FlowRelay retry Shopify handoff after Shopify throttling or temporary unavailability while the receipt shows a waiting-to-retry state.
- Use manual review when the receipt says Shopify Flow may already have received the handoff.
- Do not look for merchant-configurable retry schedules or retry policy controls in FlowRelay.
- Use replay only after previewing current endpoint configuration, Shopify Flow readiness, duplicate side-effect risk, and grant authority.
- 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 share endpoint secrets, authentication headers, HMAC values, tokens, raw event bodies, customer records, Shopify sessions, store passwords, or database URLs in public examples.