Could retries create several records for one action?¶

Yes. A user, application, network library or queue can repeat an operation after timeout or apparent failure, turning one initiating action into several technical records.

Retry behaviour changes counts and outcomes¶

Applications may resend without receiving a response, queues can redeliver and users may click again when an interface stalls. Attempts can receive new IDs or share a correlation key; some fail before a later success.

For payments, messages or file changes, idempotency and deduplication determine whether repeated requests create one outcome or several.

Identify the retry chain before counting actions¶

Compare request, transaction, message and correlation IDs, payloads, process or session, interval and result. Establish the product's configured retry policy and whether each attempt gets a new identifier. Similar timing alone cannot exclude deliberate repeated actions.

Preserve the original and every attempt and outcome. Report the number of technical requests separately from the supported number of initiating decisions or completed effects.