Retry node configuration for idempotent write operations

Question

The Node-RED retry node manages repeated attempts for failing downstream operations using a maximum attempt count and static delay. However, the node does not inherently track whether a partial success occurred before a failure triggered the retry mechanism.

When integrating with side-effecting nodes, such as database inserts or API POST requests, there is a risk of duplicate writes if the operation succeeded on the server but the acknowledgment failed to reach Node-RED. Since the retry node does not propagate a unique transaction identifier or provide a built-in deduplication flag, downstream nodes cannot natively distinguish between an initial attempt and a retry.

How can a flow be configured to prevent duplicate writes when using the retry node without implementing custom database constraints?
  Is there a documented method to attach a persistent identifier to msg that survives the retry cycle to enable programmatic deduplication?

Tasadduq Burney · Answer

Preventing Duplicate Writes in Retry Cycles
To prevent duplicate writes when using a retry node without relying on database-level constraints, you must implement a Client-Generated Idempotency Key. Since the retry node simply re-routes the msg object back to the start of the failing sequence, any property attached to msg before it enters the retry loop will persist through every subsequent attempt.

Implementation Strategy
The most reliable method is to generate a unique transaction ID at the very beginning of the flow, before the first attempt at the side-effecting operation. This ID serves as the deduplication token that the downstream service uses to recognize retries.

Generate the Key: Use a change node or a function node to assign a UUID to msg.transactionId.
  Pass the Key: Include this msg.transactionId in the payload of your API POST request or as a specific column in your database insert.
  Server-Side Check: The receiving service must check if the transactionId has already been processed. If it has, the service should return a success response (e.g., HTTP 200 or 204) without performing the write again.

Persistent Identifiers in the Retry Cycle
There is no specialized "retry-specific" identifier because the msg object is passed by reference. Any property you add to the msg object survives the retry cycle naturally. For example:

// In a function node BEFORE the retry node
msg.idempotencyKey = require('crypto').randomUUID();
return msg;

Because the retry node does not strip properties from the msg object, msg.idempotencyKey will remain identical across Attempt 1, Attempt 2, and so on, allowing the downstream node to send the same key every time.

Verification Steps

Trace the Object: Place a debug node immediately before the side-effecting node. Verify that the transactionId remains constant across multiple retry attempts.
  Simulate Failure: Use a mock API that returns a 500 error for the first two requests and a 200 for the third. Verify via server logs that the server received the same transactionId three times but only performed the write operation once.

Required Diagnostic Detail
To refine this recommendation: Does the downstream API/Database support a unique request ID or a "Conditional Put" operation? If the downstream system cannot track request IDs, programmatic deduplication must be handled via an external cache (like Redis) within Node-RED to track transactionId status before the retry node is triggered.

Retry node configuration for idempotent write operations

1 answer

0 question comments

Preventing Duplicate Writes in Retry Cycles

Implementation Strategy

Persistent Identifiers in the Retry Cycle

Verification Steps

Required Diagnostic Detail

Your perspective belongs here.