Retry node configuration for idempotent write operations

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?