The same save creates duplicate records

1. Capture one ordinary save.

   Open Chrome Inspect, select Network and clear its request list. Save a uniquely named test item once. Count the write requests triggered by that click and inspect their responses. Record each returned id, without copying session credentials.

2. Repeat the intended operation.

   In the isolated test app, repeat that same save through the interface once, using the same test data. Count the new requests. If the app exposes an operation identifier in the request, compare it across the two attempts; identical text alone does not establish the same operation.

3. Count actual stored records.

   Reload the list and compare the record ids, not just the displayed titles. Open the test database if needed. Determine whether there are two records or whether the interface is drawing one record twice.

4. Choose the failed boundary.

   Two requests from a single click point to the submission path. One request producing two stored rows points to server processing. A retry with a new operation identifier suggests the app has not preserved the identity of the original save.

WORKSRepeating the same logical save returns the intended single stored result.

BROKENA retry creates an additional record when the operation promises one result.

Ranked in the order to investigate, not by claimed frequency.

1. The interface submits the action twice.

   Use one submission handler and prevent a second in-flight submission. Retest keyboard submission as well as the button. This improves the interface, but the backend still needs to tolerate retries.

2. The backend treats retries as new work.

   Give the logical operation a stable identifier and have the server return the recorded result for repeats. Enforce uniqueness atomically in storage; a separate check followed by an insert can still race.

3. The UI repeats one stored record.

   Repair list state or rendering using the stored id as identity. Do not delete database records until you have established that duplicate rows actually exist.

• A request can finish on the server even when the browser never receives its response. A retry must not assume the earlier operation failed.
• Stripe supports idempotency keys on POST requests. Reuse a key only for retries of the same operation and parameters, not for unrelated purchases. Your app’s own database writes still need their own duplicate protection.

When to stop and hand it over

Stop immediately if the action charges money or sends real messages. For disposable records, hand over the request count, operation identifier behavior and returned record ids if the fix needs server or database changes.