Disabling Submit Fixes the Click, Not the Lost Response

A dev.to walkthrough of a four-field order form (first name, last name, amount, price, POSTed to /api/orders) draws a line that most codebases collapse into one attribute in JSX ^[1]. Disabling the submit button while the request is in progress is useful, the post says, but it improves the user experience only and provides no technical guarantee ^[2].

The list of ways a duplicate still arrives reads better as a taxonomy than as a warning: a double click, a retry after a network error, a resent HTTP request, two handlers running close together, and a refresh or navigation back to the page ^[3]. A disabled button covers one of those, and only while the component is still mounted and still knows a request is outstanding. The case it cannot touch is the one the post opens with: the request reaches the server, the order is created, the response never reaches the client, the user submits again, and you have Order #101 and Order #102 for one intended purchase ^[4].

That failure needs operation identity. The post defines idempotency as executing the same logical operation multiple times producing no more side effects than executing it once, and puts the weight on "logical": one logical operation can become several HTTP requests through retries, timeouts, or user interaction ^[5][6]. The mechanism is a client-generated key, crypto.randomUUID() sent in an Idempotency-Key header, reused on any retry of the same operation ^[7][8]. When the server sees a key it has already handled, it can treat the request as a possible retry rather than new work ^[9].

The key alone is not enough, and the counterexample is the useful part of the piece. A client-side bug resends the same key with amount changed from 2 to 10 ^[10]. Operation identity says retry; the content has changed, and the server needs a way to determine that this is not a valid retry ^[11]. Hence the fingerprint: a stable representation of the business-relevant content of a request, the same when the effective content is the same, different when any meaningful value changes ^[12].

Most of the work in a fingerprint happens before any hashing. The post trims the name strings, coerces amount through Number, and converts price to a minor unit with Math.round(price * 100) to avoid floating-point inconsistencies ^[13]. The normalized object is then JSON.stringify'd into a canonical string, which can act directly as a local fingerprint for in-client comparison, with a SHA-256 digest of that string via crypto.subtle.digest as the compact form for persistence or server-side storage ^[14][15][16].

Note where each half stops. Content identity cannot deduplicate on its own: two genuinely separate orders with the same name, amount, and price produce the same fingerprint by construction, so a server that rejects repeated content rejects a legitimate second order ^[17]. Operation identity cannot validate on its own, which is what the changed-amount case demonstrates ^[11]. The pair is not belt and braces, it is two different questions asked about the same request.

If you are implementing this, the normalization function stops being a helper and becomes a contract. Any divergence between client and server on trimming or on the cents rounding yields different fingerprints for identical business content ^[18], which converts a retry into a conflict. The second thing to settle is what the server actually returns when the key matches and the fingerprint does not; the material here establishes that the server must be able to tell this is not a valid retry, but does not specify the response ^[11]. The post also names a third concept alongside fingerprints and idempotency, meaningful dirty state, framing the three as distinct things that prevent many common form-submission bugs when designed together ^[19].