Duplicate intent reached the gateway
UI-only disabling is too late when two calls enter before the pending state is rendered. The test sends both calls during the same in-flight window.
SELF-OWNED ENGINEERING PROOF · ISSUE ISOLATION
Duplicate checkout submission
Two near-simultaneous checkout actions could cross the payment boundary before the interface reflected its busy state. This record shows the reproduction, failure boundary, focused correction, and regression evidence.
- Scope
- One checkout boundary
- Finding
- Concurrent side effect
- Decision
- Share one in-flight request
- Verification
- 2 / 2 checks passed
FAILURE BOUNDARY
The side effect began before duplicate intent was contained.
- 01First submitPayment request starts
- 02Second submitSame cart arrives while pending
- 03Unprotected boundaryA second charge can start
- 04In-flight lockBoth callers share one result
DIAGNOSIS
What changed the outcome
No canonical request state per cart
The checkout boundary had no shared record of an active charge. Each caller could create its own promise and side effect.
Register before invoking the gateway
The controller stores the request promise by cart ID before the charge begins, returns it to duplicates, and clears it in a finalizer.
Server idempotency still belongs in production
This client boundary contains concurrent calls in one runtime. A real payment API should also enforce a server-side idempotency key across retries and devices.
VERIFICATION EVIDENCE
Acceptance checks are executable
Run with Node.js only. No application framework, payment credentials, or external service is required.
$ node --test issue-isolation-proof/checkout-controller.test.mjs
✔ concurrent submissions for the same cart create one charge
✔ a failed charge releases the cart for a clean retry
tests 2 pass 2 fail 0Acceptance conditions
- Two concurrent calls for one cart invoke the gateway once.
- Both callers receive the same successful charge result.
- A failed request releases the cart for a later retry.
- No payment secret or external account is used.
BUYER HANDOFF
A paid issue-isolation engagement returns this decision structure for your actual workflow.
Provide the affected workflow and repository or staging access. The output is a reproduction record, failure boundary, implementation path, acceptance condition, and the regression path that matters.
Open Upwork profile