DataTables serverSide retries: duplicate writes and stale draw handling

DataTables serverSide processing sends a draw counter with each request and expects the server to echo it so the client can discard stale responses. Core DataTables documents no automatic retry for failed or timed-out Ajax, and ajax.reload() may overlap an in-flight request. Writes typically live outside core DataTables in Editor or custom endpoints, so retrying a POST after an ambiguous timeout can duplicate a row unless the application defines its own idempotency semantics.

The unresolved decision is how to reconcile read sequencing with write safety. Should a failed serverSide read be retried with the same draw value or a new one, and should a stale response be ignored once a newer request has succeeded? Version-sensitive differences in ajax options, serverSide defaults, and preXhr/xhr events across DataTables 1.x and 2.x make it unclear where to enforce these rules.

Should the application mint a stable idempotency key before the first write attempt and hold it until a definitive result, or is there a supported client-side pattern to block overlapping triggers and queue retries while preserving draw ordering?