Disabling Register was not enough to prevent duplicate samples
Repeated registration requests could create multiple sample groups. A stable submission token let the server recognize the same attempt, replay its response, and guard against concurrent duplicates.
On a slow or unstable connection, a laboratory user could click Register and receive no useful feedback before clicking again. Each HTTP request could create another sample group from the same form.
Disabling the button and showing progress was an obvious improvement. But the server also needed an answer to a harder question: if the same registration arrived again, was it new work or a repeat of work already accepted?
Give the attempt an identity
The August 2026 fix introduced a registration token tied to the user and form context. Repeated submissions from the same attempt carried the same token.
Before creating samples, the server checked whether that token already had a completed registration. If it did, it returned the original response, including the existing sample references, instead of creating another group.
That changed the meaning of a retry. The browser could ask again for the outcome of its existing attempt rather than unintentionally starting another registration.
The interface still mattered: it disabled repeat submission, showed progress, and preserved the attempt token after an uncertain response. Generating a fresh token on every retry would have defeated the server's ability to recognize those requests as the same attempt.
A lookup alone leaves a race
Two copies of the request can arrive before either has finished. Both may initially find no completed registration.
If the protection ended at that lookup, both could proceed to create samples. The completion record therefore had to participate in the same database transaction as sample creation. Concurrent attempts using the same token could not both commit duplicate sample groups.
This was a case where a sequential test was insufficient. “Submit, then submit again” checked response replay. The concurrency test used two transactions to verify that the duplicate attempt rolled back when both competed to complete the same registration.
The behavior I wanted covered three different situations:
| Situation | Expected behavior |
|---|---|
| A new registration attempt | Validate the form and create its sample group. |
| A completed attempt is repeated | Return the original response. |
| Two copies of one attempt overlap | Prevent both from committing sample groups. |
The token describes an attempt, not a patient
This mechanism does not decide that two forms with similar patient details must represent the same laboratory work. A deliberate new registration needs its own attempt identity.
Its protection is also bounded by retention. Completed submission records expire; the current implementation retains them for seven days. Replaying an old token indefinitely is not a supported way to establish whether a sample exists.
That makes this different from the processor's uncertain-create lookup. There, the caller verifies whether an external order was created in another system before retrying. Here, the registration endpoint owns both the sample creation and the transactional record of the attempt.
The user-facing improvement was straightforward: Register gave clear feedback, and a safe retry could recover the original response. Achieving that required the browser and server to agree on what “the same submission” meant, including when two copies arrived at once.