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.
- When: The request was rejected, replay is unavailable, or the source intentionally needs a fresh event
  Then: Ask the external sender to resend.
- When: Shopify throttled the handoff or was temporarily unavailable
  Then: Let FlowRelay retry while the receipt shows a waiting-to-retry state.
- When: The receipt says Shopify Flow may already have received the handoff
  Then: Use manual review; do not trigger an automatic retry.
- When: You are choosing between retry, replay, and resend
  Then: Start with the receipt state: rejected, accepted, delivered, failed, duplicate-suppressed, or unavailable for replay.
- When: You are looking for a merchant-configurable retry schedule
  Then: Stop; FlowRelay does not expose retry policy controls.
- When: Replay is available and may be appropriate
  Then: Preview current setup, readiness, side-effect risk, and grant authority before confirmation.
- When: Downstream processing may already have started
  Then: Prefer manual review, diagnostics, and explicit replay confirmation.

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