Sulu optimistic locking version column returns 409 Conflict on retried content writes

Goal

Determine whether a retried Sulu content write can succeed after an optimistic-locking conflict without creating duplicate entries.

Constraints

Sulu content nodes use optimistic locking through a version column. A version mismatch produces a 409 Conflict response from the API layer. It is unclear whether the platform provides a built-in idempotency key or client token for deduplicating retries. Disabling versioning removes the conflict but removes protection against concurrent edits.

Questions

• Does Sulu provide a server-side deduplication mechanism for retried content writes?
• After receiving 409 Conflict, should a client refresh and resubmit the current version, or treat the request as failed?
• What retry pattern prevents duplicate writes when versioning is enabled?