Retries and duplicate events - Sydekyks

A mission may receive the same event more than once. A provider may retry delivery, a poll may observe a record again, or a person may retry a run after a failure.

Give each business item an identity

Choose a stable identifier from the source, such as a submission ID or a supplier-plus-bill-number combination. Store that identifier with the result. Do not use only the current timestamp when you need to recognize the same item later.

Check before writing

Look up the identifier before creating a new record. If it already exists, choose an explicit rule: skip, update, or send it for review. Provider-supported idempotency keys can help make repeated requests safe.

Classify the error

Error	Recovery approach
Invalid input	Correct the data or rule before retrying
Credential rejected	Reconnect or correct access first
Rate limit	Honor the provider’s retry timing and reduce volume
Timeout or temporary outage	Check whether the operation completed remotely before repeating it
Later step failed after a write	Inspect completed side effects and resume/retry according to the actual action behavior

Check retry settings

Review the error-handling options on the relevant step. Automatic retries and continuing after failure change how later steps execute. Keep a visible failure path for work that needs a person’s decision.

Verify recovery

Use a sample whose business identifier you can trace. Confirm that the recovery produces one intended final record and that the run history explains what happened. Avoid using real customer data to learn retry behavior.