Could retries create several records for one action?¶

Yes. Retries can create several log records from one original action.

A user, application or service may attempt the same operation again after delay, timeout or apparent failure.

Avoid the dangerous assumption¶

The dangerous assumption is that several similar records always represent several separate human actions.

They may reflect one action being retried automatically.

Applications often retry when a response is not received. Network libraries may resend requests. Message queues may deliver the same item again. A user may also click repeatedly because the interface appears unresponsive.

The resulting logs can contain several requests, authentication attempts, connection records or transaction entries. Some may fail while a later retry succeeds.

Investigators should look for shared request, transaction, message or correlation identifiers. Exact or near-identical payloads, regular intervals and the same session or process may also support a retry explanation.

But retries must not be assumed merely because records look similar. Several deliberate actions can also occur close together. Establish what the application normally does after timeout or failure.

Ask whether the system uses automatic retry, how many attempts are permitted and whether each retry receives a new identifier. Preserve the original request and every subsequent result.

Where money, messages, file changes or account actions are involved, determine whether retries created duplicate outcomes or whether the system used deduplication to complete the action only once.

Do not count log entries as offender actions without analysing the retry behaviour.

Operational takeaway¶

Retries can turn one initiating action into several technical records, so investigators should examine identifiers, timing and application behaviour before counting events or inferring repeated intent.