Ajax error after a committed create: retry duplicates in DataTables Editor

The failure window

In a DataTables server-side setup, row writes run through the Editor extension's create, edit and remove callbacks, or an equivalent custom submit path. A request can fail at the Ajax layer — a timeout, a non-200 response, malformed JSON — after the server has already committed the insert. The failure is surfaced to the user, but retry handling and deduplication are left to the application.

From the client, “never reached the server” and “response lost after commit” look identical. An automatic retry can therefore insert the row twice, while no retry leaves the table stale. The goal is to pick one ownership model for retry safety — client retry keyed on an idempotency token, server-side deduplication, or user-driven retry — and define how the table reconciles after a failed write.

Constraints

• Editor does not generate idempotency keys; any token must originate in application code.
• Error-handling APIs differ between the 1.9 and 1.10+ generations, so the exact failure surface should be confirmed against the installed version's documentation.

Open questions

1. Is there a supported hook for attaching a client-generated idempotency key to an Editor submit, or must it ride in custom submission data?
2. After a create fails post-commit, is a re-fetch and redraw the expected reconciliation, or does Editor offer any state rollback?