Turbo Drive form write with Turbo Stream no-op on missing target hides whether the write occurred

Direct answer

No. When Turbo Drive submits a form and the server returns a 2xx Turbo Stream whose target DOM ID is absent from the page, Turbo Drive treats the response as successful. The stream action is a silent no-op: no DOM change, no error, and no automatic retry. Because Turbo Drive does not attach idempotency keys, the client has no reliable signal that the write was applied, and a manual page refresh or second submit may repeat a non-idempotent POST, PUT, or DELETE.

Likely explanation

Turbo Drive sends form submissions through fetch. On a 2xx response with text/vnd.turbo-stream.html, it parses the stream instructions and applies them to matching DOM IDs. If the target ID does not exist, the instruction does nothing. Turbo operates at the HTTP and DOM layer, so it cannot see whether the server’s business logic executed the write before rendering that stream. A missing target only proves the DOM was not updated; it proves nothing about the server-side write.

Confirmed facts

• Turbo Drive does not automatically retry submissions.
• Turbo Drive does not generate or attach idempotency keys.
• A Turbo Stream action against an absent DOM ID produces no error event.
• A 2xx response means the response was received, not that the business write succeeded.
• Without server-side idempotency state, retrying can duplicate the write.

Steps for this case

1. Confirm the installed Turbo version. Turbo v7 and v8 share this limitation, but stream-action details can differ; check the lockfile, importmap, or window.Turbo?.version in dev tools.
2. Add a hidden idempotency key to the form, generated by the server when the form is rendered. Turbo Drive serializes the field with the form body automatically, so no per-page JavaScript is required.
3. On the server, persist the key with the write result before responding. On a repeated key, replay the stored outcome instead of executing the write again.
4. Do not offer a client-side retry after a silent no-op unless the server can confirm the write was not applied or can safely replay a stored response.
5. Use a safe GET refresh to re-read state after submission. This does not resubmit the original write.

Missing diagnostic detail

Does the server currently persist idempotency keys or request fingerprints? This determines whether a retry can be made safe or whether retries must be blocked and the write investigated manually.

Verification

In browser dev tools, submit the form and inspect the Network panel. Confirm a 2xx response with Turbo Stream content, verify the target ID is absent from the current DOM, confirm no error or DOM change occurs, then check the server audit log to see whether the write was applied. If idempotency exists, resubmit with the same hidden key and verify the server returns the stored outcome without a second side effect.

Assumptions and uncertainty

This assumes Turbo Drive is enabled and the response is processed as a Turbo Stream in the current page. Turbo v7 and v8 share this limitation, but confirm the installed version because behavior can differ. DELETE and PUT may be idempotent by HTTP semantics but can still have non-idempotent side effects. Client-side MutationObserver detection is only a heuristic and is not a Turbo guarantee.