Duplicate records appear although the submit control is disabled while a request is in flight. What got past the guard?

## Why the disabled control is not the guard Disabling the submit control while a request is open stops one thing: another press on that control. It is worth having — it is the cheapest feedback in the form — but it is not where duplicate protection lives. Enumerate the paths that bypass it: 1. **Another control starts the submission.** A second button with a different intent, a control elsewhere on the page, a shortcut key bound to save. Only the disabled one is disabled. 2. **The flag is not readable yet.** Two events land in the same frame; both handlers read the value as it was before either wrote it. 3. **The flag is set too late.** The handler awaits something — reading a file, asking for confirmation, computing a token — and only then marks itself pending. Everything before that point is an open window. 4. **The component remounts.** A navigation, a changed key, a parent re-creating the subtree: the flag is local state and it comes back as idle while the earlier request is still in flight. 5. **The response is lost, not the write.** The user retries, or the client retries automatically, and the server records a second write because the first one succeeded and only its answer went missing. Only the first four are client-side bugs. The fifth is the reason a purely client-side story can never be complete. ## The flag has to be readable synchronously Rendered state is designed to drive rendering, and how fast a write becomes visible to a reader depends on the reactivity model. In a runtime that **re-runs the component function** on each write, the handler closes over the values from the run that created it, so a value it just wrote still reads as the old one for the rest of that handler — and for any other handler created in the same run. In a **fine-grained** runtime, a write is visible to the next read immediately. In a **compile-time** runtime the assignment becomes a notification, and the read may or may not be reordered before the re-render. Because the answer differs, the portable guard does not depend on it: hold the in-flight marker in something the handler reads and writes directly — a mutable holder attached to the component instance, or the in-flight request itself, kept in a module-scoped map keyed by the record being written. The rendered flag remains, but it now reflects the guard rather than being it. A neat expression of the same idea: keep the in-flight promise. If one exists for this form, the handler returns it instead of starting a second request. The guard and the deduplication are then the same object. ## Where a framework-tracked submission helps When the framework itself tracks a submission started through the form as one unit of work, with its own pending status and result, two of the five paths close for free: the tracked status covers every path the framework routes through that submission, and the status settles even when the handler throws. It does not close the remount case, and it certainly does not close the lost-response case. So a tracked submission replaces your flag; it does not replace your idempotency story. ## The retry case: idempotency A write whose response is lost is indistinguishable, from the client, from a write that never happened. The only correct resolution is for the second attempt to be recognisable as the same attempt: - Generate a **request key once per user attempt** — not once per retry — and send it with every retry of that attempt. - The server records the key with the write and, on seeing it again, returns the original result instead of writing again. - A natural uniqueness constraint on the record can substitute where one exists, at the cost of a much worse error to present. The key must be regenerated when the user genuinely starts a new attempt, or a legitimate second submission will be swallowed as a duplicate. ## Layers, in order of strength | Layer | Closes | Leaves open | |---|---|---| | Disabled submit control | repeat presses on that control | every other path | | Rendered pending flag | slow double presses across renders | same-frame events, remount | | Synchronous in-flight marker or shared promise | all client-side duplicate starts | lost response, second tab | | Request key honoured by the server | duplicate writes, whatever the cause | nothing relevant | ## How you find this in production Duplicates are usually reported as data, not as a UI bug: two identical records seconds apart, the second with the same payload. Measure it — a duplicate-write rate per endpoint — because it is the only way to know whether a fix worked. Then test the paths individually: a rapid double press, a keyboard-triggered submit, a submit followed immediately by a navigation, and a forced retry with the response dropped.