Limits of Backbone.sync retry behavior for model writes

Short answer

No — Backbone.sync should not gain a built-in, default-on retry mechanism, and it does not have one today. The default sync simply delegates to Backbone.ajax (which wraps jQuery.ajax by default), and one model.save() call produces exactly one HTTP request. Any retry behavior you see in an app comes from somewhere else — a jQuery transport, a service worker, a proxy, or an application-level wrapper — not from Backbone.

Why a default retry is dangerous

sync picks the HTTP verb from model.isNew(): a model without an id is saved with POST to the collection URL, while a model with an id is saved with PUT (or PATCH with {patch: true}) to the model URL. Blindly retrying a POST create after a network failure can duplicate the write: the first request may have succeeded server-side even though the response never arrived. Also note that save() does not deduplicate concurrent calls — two saves on a new model already produce two POSTs, so adding automatic retries on top would multiply that risk.

If you add a retry option anyway

A reasonable opt-in policy (off by default):

• Attempts: about 3 total, exposed as an option.
• Backoff: exponential with jitter, base delay around 500ms–1s with a cap.
• Retryable failures: network-level errors and 5xx responses; optionally 429 honoring Retry-After. Never auto-retry 400/401/403/422 — they will fail identically.
• Semantics to preserve: call options.success/options.error exactly once, after the final attempt (the request event may fire per attempt), and serialize the payload once before the first attempt so retries don't pick up attribute changes made while a retry is pending.

Enforcing idempotency

The library (or your wrapper) can make retries safe in two ways:

1. Client-generated ids: set the id before the first save(). This converts the create into an idempotent PUT to a deterministic URL like /collection/<id>. Caveat: this only works if your API accepts client-supplied identifiers; it breaks against servers that assign auto-increment ids.
2. Idempotency keys: generate one key per save() call and resend it as a header on every attempt, so the server can deduplicate. A retry wrapper should skip retries for POST unless one of these mechanisms is present.

Treat PATCH like POST unless verified: it is only idempotent for set-to-value semantics, not for handlers that increment or append.

Scoping the override

Prefer overriding Backbone.ajax or defining a sync function on individual model/collection classes rather than replacing Backbone.sync globally. A global override changes fetch, save, and destroy for every model and collection in the app and can silently alter unrelated code paths.

Verifying your setup

• Read Backbone.sync and Backbone.ajax in your installed node_modules/backbone/backbone.js to confirm there is no retry option and to see how the ajax call is made — internals vary by version, so check against your lockfile.
• Stub Backbone.ajax to log calls; save a new model and a persisted model and confirm one POST and one PUT, with no second call after a failure.
• Prototype the wrapper against a stub that returns 500 once then 200; verify success fires once, the payload is identical across attempts, and a retry PUTs to /collection/<id> when a client id is set.

One caveat: Backbone is effectively in maintenance mode, so expect an adapter or plugin rather than an upstream core change. The deciding detail for your design is server capability — whether it accepts client ids or honors an idempotency-key header determines which mechanism to use.