Does Jira Align’s sync retry mechanism prevent duplicate writes during transient failures?

Goal

Determine whether Jira Align’s bidirectional sync engine treats retry attempts after a transient failure as idempotent operations, so that a retry does not result in duplicate writes to either Jira Align or Jira Software.

Constraints and uncertainty

The sync runs every few minutes, uses a last‑write‑wins strategy based on detected timestamps, and provides no user‑visible conflict resolution or merge capability. Documentation does not specify whether the engine attaches a unique identifier or version token to each change attempt that could be used to recognize a retry and skip re‑application.

Specific questions:

• Does the sync engine assign a unique transaction ID or version stamp to each change attempt that is checked on retry to avoid duplicate writes?
• If a retry occurs after the target record already reflects the same timestamp, is the operation treated as a no‑op?
• What mechanisms, if any, prevent a retry from re‑applying an already‑applied update and causing a duplicate write or unintended overwrite?