Replay & retry

Outcome

A failed inbound is re-parsed, and an outbound 837 that failed to send is replayed cleanly: the replay runs on the customer you have selected, retries the same transaction record (no duplicate row), and the operator can tell from that one record what was attempted and what happened.

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.
Replay outbound 837	A claim whose 837 failed to send (SUBMISSION_FAILED)	Re-builds the 837 from the claim and sends it again, on the same transaction record.

Replay outbound 837 — the rules

• Selected customer only. The replay reads and writes the database of the customer selected in the console header. A transaction id from another customer answers 404 not found, even if the id is real.
• Failed outbound 837s only. Anything else — an inbound file, a 270/276, an 837 that is still PENDING, or one already SUBMITTED or acknowledged — is refused with 409 REPLAY_NOT_ELIGIBLE and nothing changes. An 837 that reached the partner is never re-sent from here.
• Same record, not a new one. The failed transaction is reset and sent again in place: it gets a freshly built 837 with new control numbers, but keeps its transaction id, its claim link and its history. There is never a second outbound 837 row for the same claim.
• Three attempts. The record's Retries count includes the first failed send. Each failed replay adds exactly one; at 3 the replay is refused. Before each attempt the gateway waits 1, 2 or 4 seconds (longer for each earlier failure).
• Outcome. Success moves the record to SUBMITTED, records the claim's submission and moves the claim to SENT; Retries does not change. A failure answers 422 REPLAY_FAILED, leaves the record at SUBMISSION_FAILED with Retries up by one, and writes the reason to its Error Details.

Idempotency rules

Operation	Idempotent?	Why
Re-parse inbound	Yes	The parser is deterministic on the same input.
Replay outbound 837	Yes, per claim	One transaction record per claim; only a record that never reached the partner is re-sent.

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 replay a failed outbound 837

A row in the Failed Queue on /replay (status SUBMISSION_FAILED):

1. Check the customer selector. The replay acts on the selected customer's database only. If the transaction is not found, you are on the wrong customer.

2. Read the failure. Open the transaction and read Error Details. If the partner's transport is broken (SFTP outage, credentials), run a Test connection (2.5) and fix it first — a replay against a broken transport just spends an attempt.

3. Click Replay (or tick several rows and Replay Selected). The platform re-builds the 837 from the claim, allocates fresh control numbers, and sends it on the same transaction record.

4. Read the result. On success the record shows SUBMITTED; watch for its 999 and 277CA. On failure it stays in the Failed Queue with Retries one higher and the new reason in Error Details.

A stuck outbound — SUBMITTED but no acknowledgment — is not replayable here: the partner may already have it. Check the partner's portal and follow RCM runbook §3 instead.

Bulk replay

/replay supports filtering and bulk action on the Failed Queue:

1. Filter by transaction type, trading partner, or date range.

2. Select rows and click Replay Selected. Each row is replayed one after another under the rules above, on the selected customer.

3. Read the summary — how many replayed and how many failed. A row already at 3 retries, or no longer a failed outbound 837, counts as failed and is left unchanged.

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.
Replay of a failed 837 keeps the same transaction id	Yes — one outbound 837 record per claim, now SUBMITTED.
Replay of a transaction from another customer	404 — switch the customer selector.
Replay of anything but a failed outbound 837	409 REPLAY_NOT_ELIGIBLE — nothing changes.
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.
Replay answers 404 for a transaction you can see in search	A different customer is selected	Select the transaction's customer and retry.
Replay answers 409 REPLAY_NOT_ELIGIBLE	Not a failed outbound 837 (already sent, pending, inbound, or another type)	Nothing to replay; for a sent claim with no ack, see the stuck-outbound note above.
Replay refused at 3 retries	The attempt budget is spent	Fix the cause in Error Details, then follow RCM runbook §3 to force a resubmission.
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