Submitting an instrument again before the first save completes creates a duplicate record #1668

Activity

1. joshunrau

   added

   BugType: existing behavior is wrongType: existing behavior is wrong

   Priority: HighSignificant or frequently hit user impact; target the next release or twoSignificant or frequently hit user impact; target the next release or two

   Difficulty: LowIsolated change, about 2 hours or lessIsolated change, about 2 hours or less

   Area: SharedCross-tier packages (schemas, react-core, etc.) not covered by another areaCross-tier packages (schemas, react-core, etc.) not covered by another area

   on Oct 7, 2026
2. joshunrau commented on Oct 26, 2026

   

   joshunrau

   on Oct 26, 2026

   CollaboratorAuthor

   More actions

   Still reproduces on main (d86740e). None of ScalarInstrumentRenderer.tsx, SeriesInstrumentRenderer.tsx, FormContent.tsx or InteractiveContent.tsx has changed since the issue was filed, and no open PR touches them.

   The suggested fix needs four changes

   1. The ref is the guard. The returned promise is not. libui 6.16.1's handleSubmit (src/components/Form/Form.tsx:132-166) has no re-entry check. isSubmitting only renders an overlay that blocks clicks (:200), and it is raised after an await on validation (:134, :150). Keyboard input goes straight past it. Submit is disabled only under suspendWhileSubmitting (:189, :257), which FormContent does not pass and which holds every submit for at least 500 ms (:153-155). So if only the promise is returned, Enter on the focused Submit button still saves twice.

   2. A dropped call has to return the pending save, not undefined. Once FormContent returns the promise, libui awaits the second call too. A bare return resolves at once, so libui runs reset() (:162) and setIsSubmitting(false) (:164) while the first save is still running. That empties a resetButton form mid-save (Forms with a reset button are emptied on submit even when the save fails #1673 again) and drops the overlay. Keep the save promise in the ref and hand it back to any repeat call.

   3. In the series, "cleared only when onSubmit rejects" blocks every item after the first. Key the slot on the item:

      const pendingSave = useRef<null | { itemIndex: number; promise: Promise<void> }>(null);
      
      // first line of the handler
      if (pendingSave.current?.itemIndex === currentItemIndex) {
        return pendingSave.current.promise;
      }
      // ...validation and terminate, unchanged...
      const promise = save(); // the existing `await onSubmit(...)` and the state updates after it
      pendingSave.current = { itemIndex: currentItemIndex, promise };
      promise.catch(() => {
        pendingSave.current = null;
      });
      return promise;

      A boolean cleared on success would also let a stale submit through. If item k's form submits after its save resolves but before React renders item k + 1, that handler's closure still has currentItemIndex === k.

   4. Set the slot only after validateSubmission passes. Validation and terminate are synchronous, so nothing interleaves between the check and the set. The validation-failure return (a bare return today, { success: false, errorMessage } after Forms with a reset button are emptied on submit even when the save fails #1673) then never holds the guard.

   The scalar renderer takes the same shape with a plain useRef<Promise<void> | null>. It is never cleared on success, because a successful save moves to the summary (setIndex(2)). For INTERACTIVE items, clearing on rejection gives no retry, because the task has already ended. That is #1535's INTERACTIVE row, and this guard cannot fix it.

   Tests to add

   • ScalarInstrumentRenderer.test.tsx: it('should keep the answers of a resettable form when it is submitted again while saving') and it('should accept a resubmission once the save rejects, so a failed save can be retried'). Drive the second test with the FILE instrument. FileInstrumentContent catches the rejection and re-enables Submit. A rejected FORM save instead escapes libui's void handleSubmit(event) as an unhandled rejection, which fails the vitest run.
   • SeriesInstrumentRenderer.test.tsx:191 already fails if the guard blocks the second item.
   • e2e, instrument-completion.spec.ts: hold POST /v1/instrument-records with page.route (as error-page.spec.ts:13 does) and click Submit. Then call submitButton.press('Enter'), release the request, and assert one POST and one row. press has no actionability checks, so it gets past the overlay where a second click() would wait on it. The test therefore fails if only the promise is returned.

   Order

   Land #1673 first, then this. Rule 2 only applies once FormContent returns the promise, and both change FormContent.tsx:61 and both createSubmitHandlers. #1680 changes handleDoneEvent, the INTERACTIVE caller of the same handler, so the three fit in one PR with one commit each. Land this before #1750, which adds itemIndex to the same onSubmit({...}) call at SeriesInstrumentRenderer.tsx:99-106. #1825 appends tests to instrument-completion.spec.ts, so expect a trivial rebase. #1713 (a FILE retry creates a second record) and #1641 (the Breakout Task calls done twice) still need their own fixes. This guard only stops a second call while the first save is pending.

   _{Triage note written with Claude Code. Code references point at main @ d86740e.}