A red n8n execution does not tell you whether the requested action happened. The receiver may have committed the change and lost the acknowledgement. Look up the effect before asking for it again.

Fictional incident: an invoice event creates a local review-queue item, then loses its acknowledgement. All identifiers and records below are illustrative; outcomes are expected, not observed. No n8n workflow, transaction or failure drill was executed. Despite the event’s name, no email or reminder is sent.

One event, three deliveries

The starting invoice is inv-demo-101, belonging to acct-demo-A, with status=unpaid and reminder_allowed=true. The effects and completions collections are empty. Eligibility here permits preparing a review item only.

All three fictional deliveries carry these shared fields:

Event ID
evt-demo-701
Event type
invoice.reminder_requested
Requested at
2026-09-13T10:00:00Z
Payload version
1
  1. First delivery: del-demo-01. Account acct-demo-A; invoice inv-demo-101. Ask the local receiver to create the review item.
  2. Same-payload repeat: del-demo-02. Account acct-demo-A; invoice inv-demo-101. Only the delivery ID changes. This is another delivery of the same business request, not a second job.
  3. Conflicting repeat: del-demo-03. Account acct-demo-B; invoice inv-demo-999. The event ID is reused with different business data. Reject that conflict; do not silently return success or create another effect.

For this fixture, use event_id as the globally unique business identity. Store and compare its canonical business payload: event type, account, invoice, requested time and payload version. Exclude delivery_id, so redelivery matches but a changed account or invoice does not.

The effect and its identity must commit together

The proposed receiver must commit the deduplication identity, canonical payload and local review_queue_item in one atomic transaction, with UNIQUE(event_id) on effects. The caller records completion separately, after that durable commit.

A crash between reservation and effect can leave a reserved event with no review item. An in-memory set cannot establish durability across restarts either. On a uniqueness conflict, compare the stored business payload; do not treat every duplicate key as success. These requirements still need testing. An n8n node does not guarantee them.

An external email send cannot be folded into this local transaction. Sending would need the provider’s repeat and lookup contract, plus separate recipient and notification rules.

At the lost acknowledgement, choose lookup or repeat

Expected sequence, not an observed run: the receiver accepts del-demo-01 and commits effect review-demo-701. Interrupt the acknowledgement before the caller receives that ID. The caller has no completion record and must mark the effect’s status unknown, not absent.

Reconcile without repeating the command

Look up the local effect by evt-demo-701, including after a caller restart. The expected result is review-demo-701 for the original account and invoice. Check that match, then upsert the completion referencing that existing effect. No second creation request is needed.

Repeat under the receiver’s contract

Submit del-demo-02 with the same event ID and canonical business payload. The expected receiver response identifies the existing review-demo-701, without inserting another review item. The caller can then reconcile completion. This path depends on the atomic contract actually being implemented and tested.

Reject the changed payload

Submit del-demo-03. The expected result is a key/payload conflict, no new effect and manual investigation. Do not replace the original account or invoice. A conflict is not a successful replay.

If lookup fails or cannot establish authoritative state, leave the event unresolved. A failed lookup is not evidence that nothing happened.

Expected final records after reconciliation

The fixture should end with exactly one effect and one completion after either valid recovery path, with the conflicting delivery rejected. These are assertions for a future test, not exported rows.

Effects: one row

Event: evt-demo-701
Effect: review-demo-701
Account: acct-demo-A
Invoice: inv-demo-101
Kind: review_queue_item

Completions: one row

Event: evt-demo-701
Effect: review-demo-701
State: reconciled

The initial invoice remains unchanged. A reconciled completion means the local review item was accounted for; it does not mean a customer was contacted.

What the n8n controls actually change

The following documentation was checked on 13 September 2026. It describes mechanisms, not results from this fixture.

  • Node retries: HTTP Request offers Retry on Fail, Max Tries and Wait Between Tries (ms). These settings control node retries and delay, not deduplication of the called operation. Do not infer exponential backoff or a measured total call count from these labels. HTTP Request retry settings.
  • Failure routing: an error workflow starts with Error Trigger; Stop And Error can deliberately fail an execution. Error handling. Test the automatic execution path: a manual editor failure cannot test the automatic Error Trigger. Error Trigger restrictions.
  • Manual recovery: retrying with the original workflow and retrying with the currently saved workflow are distinct options, both using previous execution data. Record which version you choose; changing the workflow can change what the replay does. Execution retry options.
  • Investigation records: execution.id requires a saved execution and is absent when the main workflow fails at its trigger. Do not make that ID your only way to find the product event. Error data fields. Production redaction hides node input and output data; it is not proof of deletion. Check saving and redaction settings in the target environment. Workflow settings.

Keep this incident in the review queue

For evt-demo-701, locate review-demo-701, check its account and invoice, and reconcile completion. Do not send a reminder or automatically replay the disputed del-demo-03.

Before enabling recovery, test concurrent same-payload repeats, acknowledgement loss after commit and caller restart against the expected final records. Assert conflict rejection, completion linked to a real effect, and no external email or network-effect path. Test the automatic Error Trigger separately in the intended n8n configuration. These tests remain unexecuted; the fixture does not establish exactly-once behaviour.