Replay & retry

Outcome

A failed inbound or stuck outbound is replayed cleanly — the source data is preserved, the replay produces a fresh transaction record (idempotent where it matters), and the operator can reason about what was actually re-attempted vs. re-built.

Prerequisites

Scope	What it lets you do
edi.transaction.read	View transactions
edi.replay	Trigger replays

Familiarity with daily monitoring (8.1).

What "replay" actually means

Two distinct operations sit under the word:

Operation	Source	Effect
Re-parse inbound	A previously-received inbound file	Re-runs the parser; updates source records based on the result. The inbound file itself does not move.
Re-submit outbound	A previously-built outbound	Re-uses the same generated EDI; re-sends through transport with the existing control numbers.
Re-build & resubmit	The originating event (e.g. claim record)	Generates fresh EDI from the source — new control numbers, fresh companion guide application.

The /replay page exposes all three as separate buttons because they have very different semantics.

Idempotency rules

Operation	Idempotent?	Why
Re-parse inbound	Yes	The parser is deterministic on the same input.
Re-submit outbound	Yes per partner	Same control numbers — partners reject duplicates with TA105 = 025.
Re-build & resubmit	No	New control numbers — a successful resubmission can mean two adjudications if the partner already accepted the original.

The /replay page warns prominently before re-build & resubmit. Check the source claim's status before clicking.

Steps to re-parse a failed inbound

A row in /responses with status = failed:

1. Open the failed entry. Read the failure reason. Common causes:

   Reason	Cause
   parser_error: unexpected segment X at position Y	Malformed file (partner-side issue)
   parser_error: missing required loop	Same
   correlation_failed: TRN02 not found	Inbound's trace number does not match any outbound — usually a stale ack from a prior tenant migration

2. Decide whether the issue is data or code. If the file is malformed, reparse won't help — escalate to the partner. If the code was wrong (we updated the parser since), reparse will succeed.

3. Click Re-parse. The parser runs against the stored raw file content. The transaction record is updated in place; the failure note is replaced with the new outcome.

4. If reparse succeeds, the downstream dispatch fires — acknowledgments update source claims, 835s flow into posting, 271s update eligibility records.

Steps to re-submit an outbound

A stuck outbound — submitted status past the partner's expected ack window:

1. Confirm the partner did not silently process it. The most common cause of "stuck" is the partner did process it; their ack got lost. Check the partner's portal for the claim. If they show it received, do not resubmit — replay the ack instead.

2. Check the partner's transport. SFTP outage? AS2 cert expired? Run a Test connection (2.5). If the transport itself is broken, fix it; the next normal cycle picks up the stuck file.

3. If the partner has not received it and the transport is healthy, click Re-submit. The platform re-uses the existing EDI string and existing control numbers. The partner's idempotent handling (matching on ISA13) will recognize the duplicate and either re-process or return TA105 = 025. Both outcomes are acceptable.

Steps to re-build & resubmit

Use only when the original EDI was wrong (e.g. a companion guide rule was buggy and produced rejected output) and the partner's prior copy is not in adjudication:

1. Confirm prior submission's terminal state. Open the source claim's status — must be BUILT or REJECTED. Never rebuild when status is ACCEPTED, PAID, or DENIED — that produces a duplicate at the payer.

2. Verify the underlying issue is fixed. If you are rebuilding because of a companion guide bug, the fix must be deployed first.

3. Click Re-build & resubmit. The platform regenerates the EDI from the source claim, allocates fresh control numbers, applies the (now-fixed) companion guide, and submits. A new transaction record is created — the old one stays for audit.

4. Watch the new ack chain. The new submission should produce a clean 999 and 277CA.

Bulk replay

/replay supports filtering and bulk action:

1. Filter by partner, transaction type, status, date range, or correlation tag.

2. Select rows. The page enforces no-mixed-operation — a bulk selection must be all the same kind of replay. Mixing reparses with re-builds requires two passes.

3. Click the matching button. The platform processes them one at a time with rate-limiting (default: 1 per second per partner) so the partner does not see a thunderclap.

4. Watch the bulk progress at /replay/jobs/:id. Each row's outcome is logged; failures roll up into a summary.

Quarantine

Inbound files that cannot be parsed even after multiple replays land in quarantine at /responses?quarantine=true. Quarantined files:

• Do not block other inbound traffic.
• Carry the original file content (preserved in storage).
• Carry every parse attempt's error.
• Stay until manually resolved (delete + flag partner for malformed, or eventually reparse after a parser fix).

Validation

Check	Expected
Re-parse updates the existing transaction record	Yes — no duplicate row.
Re-submit returns the original or a new 999	Yes; the original control number is in the file.
Re-build creates a new transaction record with new control numbers	Yes — old record stays.
Bulk replay rate-limits to partner-respectful cadence	Yes — confirm in the bulk job's progress.

Troubleshooting

Symptom	Cause	Fix
Re-parse keeps failing with same error	Code change is needed (parser bug)	File an issue with the raw inbound; resolve via deploy.
Re-submit returns TA104 = R TA105 = 025	Partner already processed the original; duplicate detected	Confirm with partner; mark the source as submitted; do not retry.
Re-build allocates control numbers but partner returns TA105 = 003	Sender authorization broke at the partner side	Probe / contact partner.
Bulk replay job stuck	One row's replay deadlocked	The job auto-times-out after 5 min per row; the next row continues.

Next

8.3 — Transactions search & detail