[$250] Error is not shown for the empty Quantity field after choose another subrate

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.17-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92378
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Android 13 / Xiaomi Poco F5
App Component: Money Requests

Action Performed:

Precondition:

• At least have a workspace
• Enable Per Diem and upload an Excel/CSV file with subrates to the workspace's Per Diem settings

1. Navigate to the workspace chat
2. Create a new Per Diem expense
3. Select a subrate from the picker
   Verify that after selecting a subrate, the Quantity text input receives focus automatically and no errors appear when going back from the subrates screen
4. Without filling in the Quantity, open the subrates screen again and choose another subrate

Expected Result:

Verify that this time an error is shown for the empty Quantity field.

Actual Result:

The error is not shown for the empty Quantity field after choose another subrate.
Note:

• The error will appear on the third time and so on

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7188422_1782202057563.94222_-_PR92378_-_Error_is_not_shown_for_the_empty_Quantity_field_after_choose_another_subrate.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Murugesan Natarajan
Bug ID: 7188422

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022069456754040220007
• Upwork Job ID: 2069456754040220007
• Last Price Increase: 2026-06-23

Issue Owner

Current Issue Owner: @Julesssss

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/4e528d9c8bc604634b98178b961ba006ec356ad0c9bc1bbb8ef57f255571885c

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

In the Per Diem flow, after selecting a subrate the Quantity input auto-focuses. If the user leaves Quantity empty and opens the subrate picker again to pick another subrate, the empty-Quantity error should appear immediately — but it only shows up on the third selection, not the second (off-by-one).

What is the root cause of that problem?

The Quantity TextInput is only marked as touched via its onBlur handler, and that flag is set inside a 200 ms setTimeout (FormProvider.tsx:456-469). The Per Diem form uses shouldValidateOnChange with shouldValidateOnBlur={false} (IOURequestStepSubrate.tsx:227-228), so selecting a subrate runs onValidate synchronously (FormProvider.tsx:490-491).

When the user re-opens the picker on the 2nd selection, the focused Quantity input blurs and schedules setTouchedInput('quantity{idx}') for +200 ms later. The subrate selection's synchronous onValidate then runs while quantity is still untouched, and FormProvider filters out errors for untouched inputs (FormProvider.tsx:237-241) — so the empty-Quantity error is discarded. The touched flag flips ~200 ms later, but because shouldValidateOnBlur={false} the blur path never re-validates, so the error only surfaces on the next selection.

Step-by-step data flow

1. 1st pick: select subrate → onValidate runs, quantity untouched → no error (expected). Quantity auto-focuses.
2. 2nd pick: tapping picker blurs Quantity → schedules setTouchedInput('quantity{idx}') for +200 ms. Selecting subrate → onValidate runs synchronously, but touchedInputs['quantity{idx}'] is still false → quantity error filtered out → no error (the bug).
3. ~200 ms later: blur setTimeout fires → touched = true, but onValidate is NOT re-run (shouldValidateOnBlur={false}).
4. 3rd pick: quantity now touched → onValidate → error passes the filter → error finally shown (off-by-one).

What changes do you think we should make in order to solve the problem?

Mark the Quantity input as touched synchronously at the moment a subrate is (re)selected, so the synchronous onValidate in that same selection includes the empty-Quantity error.

Preferred (targeted): expose a touchInput(inputID) method on FormProvider's imperative handle (useImperativeHandle near FormProvider.tsx:360-366) that calls setTouchedInput and re-validates, and call formRef.touchInput(\quantity${pageIndex}`)inside theonValueChange handler in [IOURequestStepSubrate.tsx:240-254](https://github.com/Expensify/App/blob/7d3ae158b36afcd456c6b9a69ca3284076547bd0/src/pages/iou/request/step/IOURequestStepSubrate.tsx#L240-L254) before/with setSubrateValue`.

What alternative solutions did you explore?

Move setTouchedInput(inputID) out of the 200 ms setTimeout in FormProvider's onBlur so the touched flag is set synchronously on blur (keeping only the validation call delayed). This fixes the race for all forms but has broader blast radius — the VALIDATE_DELAY exists to avoid Checkbox focus side-effects on web/mWeb, so it should be guarded (e.g. by shouldSetTouchedOnBlurOnly). The screen-level fix above is preferred to avoid regressing other forms.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94335) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[lorretheboy]

Proposal

What is the root cause of that problem?

In the per-diem subrate form, an input's error only renders once that input is marked "touched". onValidate filters validation errors down to touched inputs only:

App/src/components/Form/FormProvider.tsx

Lines 237 to 241 in 7d3ae15

	const touchedInputErrors = Object.fromEntries(Object.entries(validateErrors).filter(([inputID]) => touchedInputs.current[inputID]));
	if (!deepEqual(errors, touchedInputErrors)) {
	setErrors(touchedInputErrors);
	}

The Quantity field is never tapped in this flow, so the only thing that marks it touched is its own onBlur → setTouchedInput, which requires the field to have been focused first:

App/src/components/Form/FormProvider.tsx

Lines 447 to 469 in 7d3ae15

	onBlur: (event) => {
	// Only run validation when user proactively blurs the input.
	if (Visibility.isVisible() && Visibility.hasFocus()) {
	const relatedTarget = event && 'relatedTarget' in event.nativeEvent && event?.nativeEvent?.relatedTarget;
	const relatedTargetId = relatedTarget && 'id' in relatedTarget && typeof relatedTarget.id === 'string' && relatedTarget.id;
	// We delay the validation in order to prevent Checkbox loss of focus when
	// the user is focusing a TextInput and proceeds to toggle a CheckBox in
	// web and mobile web platforms.
	setTimeout(() => {
	if (
	relatedTargetId === CONST.OVERLAY.BOTTOM_BUTTON_NATIVE_ID ||
	relatedTargetId === CONST.OVERLAY.TOP_BUTTON_NATIVE_ID ||
	relatedTargetId === CONST.BACK_BUTTON_NATIVE_ID
	) {
	return;
	}
	setTouchedInput(inputID);
	// Skip validation if the screen is not focused or keyboard focus is being restored (Android mWeb)
	if (shouldValidateOnBlur && isFocusedRef.current && !getIsRestoringKeyboardFocus()) {
	onValidate(inputValues, !hasServerError);
	}
	}, VALIDATE_DELAY);

So the chain is: selecting a subrate focuses Quantity → re-opening the picker blurs it → it becomes touched → validating the next subrate change shows the empty-Quantity error.

PR #92378 broke the first link. It replaced the prompt InteractionManager.runAfterInteractions(() => focus()) with a focus that is deferred through TransitionTracker.runAfterTransitions({waitForUpcomingTransition: true}) plus requestIdleCallback:

App/src/pages/iou/request/step/IOURequestStepSubrate.tsx

Lines 240 to 254 in 7d3ae15

	onValueChange={(value) => {
	setSubrateValue(value as string);
	// Focus the Quantity input after the ValuePicker modal closes.
	// TransitionTracker's callback fires synchronously inside Reanimated's animation
	// callback (outside React's event handler), so React flushes state updates async
	// via MessageChannel. requestIdleCallback ensures focus() runs after React commits
	// and the modal's FocusTrap (web) deactivates, preventing focus from being stolen.
	TransitionTracker.runAfterTransitions({
	callback: () => {
	requestIdleCallback(() => textInputRef.current?.focus());
	},
	waitForUpcomingTransition: true,
	});
	}}

But the subrate picker is a Modal (ValueSelectorModal), not a navigation screen, so selecting a subrate never registers a navigation transition. With waitForUpcomingTransition: true the focus callback waits for a transition that never starts and only fires after the MAX_TRANSITION_START_WAIT_MS (1000ms) fallback elapses:

App/src/libs/Navigation/TransitionTracker.ts

Lines 116 to 146 in 7d3ae15

	function runAfterTransitions({callback, runImmediately = false, waitForUpcomingTransition = false}: RunAfterTransitionsOptions): CancelHandle {
	if (waitForUpcomingTransition) {
	let cancelled = false;
	let innerHandle: CancelHandle | null = null;
	// Guard against transitionStart never arriving.
	// We race promiseForNextTransitionStart against a fallback timeout.
	// Whichever resolves first wins.
	// Afterwards we clearTimeout so the fallback doesn't keep the timer alive unnecessarily.
	let transitionStartTimeoutId!: ReturnType<typeof setTimeout>;
	const transitionStartTimeout = new Promise<void>((resolve) => {
	transitionStartTimeoutId = setTimeout(resolve, CONST.MAX_TRANSITION_START_WAIT_MS);
	});
	(async () => {
	await Promise.race([promiseForNextTransitionStart, transitionStartTimeout]);
	clearTimeout(transitionStartTimeoutId);
	if (!cancelled) {
	innerHandle = runAfterTransitions({callback});
	}
	})();
	return {
	cancel: () => {
	cancelled = true;
	clearTimeout(transitionStartTimeoutId);
	innerHandle?.cancel();
	},
	};
	}

Because focus now lands ~1s late, when the user re-opens the picker before that focus arrives, Quantity was never focused → re-opening doesn't blur it → it's never touched → validating the new subrate skips the empty-Quantity error. The lagging focus lands afterward, so the field only becomes touched (and the error appears) one round later — matching "the error appears on the third time and so on."

What changes do you think we should make in order to solve the problem?

Remove waitForUpcomingTransition: true from this focus call — there is no navigation transition to wait for when a modal closes, and that flag is the only reason focus is delayed by the 1s fallback.

App/src/pages/iou/request/step/IOURequestStepSubrate.tsx

Lines 248 to 253 in 7d3ae15

	TransitionTracker.runAfterTransitions({
	callback: () => {
	requestIdleCallback(() => textInputRef.current?.focus());
	},
	waitForUpcomingTransition: true,
	});

With the default (waitForUpcomingTransition: false), runAfterTransitions runs as soon as no transition is active (i.e. right away here), and the inner requestIdleCallback still defers focus until after React commits and the modal's focus trap releases. Quantity is then focused promptly, keeping the focus → blur → touched chain in sync so the empty-Quantity error shows on the very next subrate change.

What alternative solutions did you explore? (Optional)

Restore the original behaviour at this call site by focusing via a plain requestAnimationFrame/requestIdleCallback (no TransitionTracker), since closing the modal is not a navigation transition this tracker was designed for. Either way, the fix is to stop gating the focus on a transition that never occurs.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-23 16:30:01 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Per Diem Subrate step, if you leave Quantity empty and pick a different subrate from the Subrate picker, no "This field is required" error appears under Quantity. The error only starts showing from the third subrate switch onward.

What is the root cause of that problem?

The structural cause is that error visibility on this form is gated on per-input "touched" state, and the Quantity field's touched state is registered one interaction later than the validation that should reveal its error.

1. The form runs with shouldValidateOnChange, and validate() already produces the empty-Quantity error correctly:
   

   App/src/pages/iou/request/step/IOURequestStepSubrate.tsx

   Lines 133 to 139 in 7d3ae15

   	if (quantityVal === '') {
   	addErrorMessage(errors, `quantity${pageIndex}`, translate('common.error.fieldRequired'));
   	} else if (Number.isNaN(quantityInt)) {
   	addErrorMessage(errors, `quantity${pageIndex}`, translate('iou.error.invalidQuantity'));
   	} else if (quantityInt <= 0) {
   	addErrorMessage(errors, `quantity${pageIndex}`, translate('iou.error.quantityGreaterThanZero'));
   	}

2. But FormProvider only displays errors for inputs the user has touched — it filters the validate output down to touched inputs before rendering:
   

   App/src/components/Form/FormProvider.tsx

   Line 237 in 7d3ae15

   const touchedInputErrors = Object.fromEntries(Object.entries(validateErrors).filter(([inputID]) => touchedInputs.current[inputID]));

3. Quantity is a TextInput, and InputWrapper forces shouldSetTouchedOnBlurOnly: true for every text-based input, so onFocus/onPress do not mark it touched — only onBlur does:
   

   App/src/components/Form/InputWrapper.tsx

   Lines 40 to 50 in 7d3ae15

   	// force-enable form submission. For multi-line inputs, ensure that it was requested to enable form submission for this specific
   	// input and that alternative ways exist to add a new line.
   	const shouldReallySubmitForm = isEffectivelyMultiline ? !!shouldSubmitForm && canUseHardwareKeyboard : true;
   	return {
   	// There are inputs that don't have onBlur methods, to simulate the behavior of onBlur in e.g. checkbox, we had to
   	// use different methods like onPress. This introduced a problem that inputs that have the onBlur method were
   	// calling some methods too early or twice, so we had to add this check to prevent that side effect.
   	// For now this side effect happened only in `TextInput` components.
   	shouldSetTouchedOnBlurOnly: true,
   	submitBehavior: isEffectivelyMultiline && shouldReallySubmitForm ? 'blurAndSubmit' : submitBehavior,

4. The blur handler sets touched inside a 200ms timeout, and this form sets shouldValidateOnBlur={false}, so a blur marks Quantity touched but does not re-run validation:
   

   App/src/components/Form/FormProvider.tsx

   Lines 447 to 469 in 7d3ae15

   	onBlur: (event) => {
   	// Only run validation when user proactively blurs the input.
   	if (Visibility.isVisible() && Visibility.hasFocus()) {
   	const relatedTarget = event && 'relatedTarget' in event.nativeEvent && event?.nativeEvent?.relatedTarget;
   	const relatedTargetId = relatedTarget && 'id' in relatedTarget && typeof relatedTarget.id === 'string' && relatedTarget.id;
   	// We delay the validation in order to prevent Checkbox loss of focus when
   	// the user is focusing a TextInput and proceeds to toggle a CheckBox in
   	// web and mobile web platforms.
   	setTimeout(() => {
   	if (
   	relatedTargetId === CONST.OVERLAY.BOTTOM_BUTTON_NATIVE_ID ||
   	relatedTargetId === CONST.OVERLAY.TOP_BUTTON_NATIVE_ID ||
   	relatedTargetId === CONST.BACK_BUTTON_NATIVE_ID
   	) {
   	return;
   	}
   	setTouchedInput(inputID);
   	// Skip validation if the screen is not focused or keyboard focus is being restored (Android mWeb)
   	if (shouldValidateOnBlur && isFocusedRef.current && !getIsRestoringKeyboardFocus()) {
   	onValidate(inputValues, !hasServerError);
   	}
   	}, VALIDATE_DELAY);

   
   (That false is deliberate — commit "Disable blur validation in subrate step", PR #54760 — so it must be preserved, not reverted.)
5. The picker's onValueChange focuses Quantity after a pick but never touches it, and FormProvider.onInputChange runs onValidate before it calls the field's onValueChange:
   

   App/src/pages/iou/request/step/IOURequestStepSubrate.tsx

   Lines 240 to 254 in 7d3ae15

   	onValueChange={(value) => {
   	setSubrateValue(value as string);
   	// Focus the Quantity input after the ValuePicker modal closes.
   	// TransitionTracker's callback fires synchronously inside Reanimated's animation
   	// callback (outside React's event handler), so React flushes state updates async
   	// via MessageChannel. requestIdleCallback ensures focus() runs after React commits
   	// and the modal's FocusTrap (web) deactivates, preventing focus from being stolen.
   	TransitionTracker.runAfterTransitions({
   	callback: () => {
   	requestIdleCallback(() => textInputRef.current?.focus());
   	},
   	waitForUpcomingTransition: true,
   	});
   	}}

   
   

   App/src/components/Form/FormProvider.tsx

   Lines 482 to 499 in 7d3ae15

   	onInputChange: (value, key) => {
   	const inputKey = key ?? inputID;
   	setInputValues((prevState) => {
   	const newState = {
   	...prevState,
   	[inputKey]: value,
   	};
   	if (shouldValidateOnChange) {
   	onValidate(newState);
   	}
   	return newState as Form;
   	});
   	if (inputProps.shouldSaveDraft && !formID.includes('Draft')) {
   	setDraftValues(formID, {[inputKey]: value});
   	}
   	inputProps.onValueChange?.(value, inputKey);

This chain explains every symptom, including the exact "third time":

• Pick 1: on-change validate runs → Quantity not touched → error filtered out (step 2); then Quantity gets focus, which does not touch it (step 3). (No error — matches expected.)
• Pick 2: reopening the picker blurs Quantity → it becomes touched ~200ms later, but shouldValidateOnBlur={false} means no re-validate (step 4), and that pick's own on-change validate already fired with Quantity still untouched. (Still no error — the bug.)
• Pick 3+: Quantity is already touched from pick 2's blur, so the on-change validate now keeps the error. (Error finally shows.)

Affected paths: the single Subrate onValueChange (L240) covers both the add-subrate branch (parsedIndex === filledSubrateCount) and the update/edit branch, plus the backTo edit-from-confirmation entry; all use the same quantity${pageIndex} key, so every subrate slot is affected. Repro is Android & iOS app and the file is shared .tsx, so the fix is platform-agnostic. The Subrate field itself is unaffected because it is touched via onPress.

What changes do you think we should make in order to solve the problem?

Mark the Quantity input as touched when the subrate changes, so the next on-change validation surfaces the required error. Expose a setTouchedInput(inputID) on FormProvider's imperative handle (sibling to the existing resetFormFieldError,

App/src/components/Form/FormProvider.tsx

Lines 346 to 354 in 7d3ae15

	const resetFormFieldError = useCallback(
	(inputID: keyof Form) => {
	const newErrors = {...errors};
	delete newErrors[inputID];
	setFormErrors(formID, newErrors as Errors);
	setErrors(newErrors);
	},
	[errors, formID],
	);

) and call it from the picker:

onValueChange={(value) => {
    setSubrateValue(value as string);
    formRef.current?.setTouchedInput(`quantity${pageIndex}`);
    // ...existing focus block stays unchanged...
}}

Because onValueChange runs after FormProvider's own validate (step 5), pick N marks Quantity touched and pick N+1 displays the error — so the first pick stays clean (matches the expected "focus, no error") and the second pick shows the error. Regression safety: it adds one touched flag for one field on this one form; valid quantities still show no error, and a brand-new empty field shows nothing until the user switches subrate.

Why the obvious one-line fixes do not work: Removing the touched filter (L237) or forcing the error unconditionally would flash "required" on Quantity the instant the screen opens — before any interaction — regressing every touched-gated form. Re-enabling shouldValidateOnBlur reverts the deliberate PR #54760 change and still depends on the 200ms-delayed blur-touch landing before the next pick, reintroducing a race. And setTouchedInput must run directly in onValueChange, not inside the focus block's requestIdleCallback (web-only), or native would never mark it touched.

What alternative solutions did you explore? (Optional)

• Call validate() directly in onValueChange — incomplete: FormProvider validates before onValueChange, so the error still lags one pick unless Quantity is already touched.
• Set shouldValidateOnBlur back to true — rejected: reverts intentional PR #54760 and races the 200ms blur-touch.
• For the record, PR #92378 (the InteractionManager→TransitionTracker focus migration at L240-L254, where QA caught this) only changed how focus is scheduled; validation is untouched, so it is not the cause.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-23 16:26:28 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Per Diem subrate screen, after selecting a subrate the Quantity field is auto-focused but left empty. When the user reopens the subrate picker and selects a different subrate without filling Quantity, the "field required" error for Quantity should appear immediately but does not. The error only shows up on the third subrate selection and onward, so the validation feedback is consistently one selection cycle late.

What is the root cause of that problem?

The Quantity error is computed correctly on every subrate change, but it is filtered out because the input is not yet marked as touched at the moment validation runs. In FormProvider, onValidate only keeps errors for inputs whose touched flag is already set, and that flag for quantity{pageIndex} lags one full selection cycle behind.

App/src/components/Form/FormProvider.tsx

Lines 237 to 241 in 7d3ae15

	const touchedInputErrors = Object.fromEntries(Object.entries(validateErrors).filter(([inputID]) => touchedInputs.current[inputID]));
	if (!deepEqual(errors, touchedInputErrors)) {
	setErrors(touchedInputErrors);
	}

Two things make the touched flag lag. First, the Quantity field is a TextInput, so InputWrapper registers it with shouldSetTouchedOnBlurOnly: true; it is therefore only marked touched inside the onBlur handler, and even there setTouchedInput runs inside a setTimeout(..., VALIDATE_DELAY) (200ms) rather than synchronously. Second, IOURequestStepSubrate sets shouldValidateOnBlur={false}, so blurring Quantity never re-runs validation — the only thing that runs onValidate is shouldValidateOnChange firing when the subrate value changes:

if (shouldValidateOnChange) {
    onValidate(newState); // runs synchronously on subrate change
}

So the sequence is: select subrate #1 → validate (Quantity not touched, error filtered) → focus Quantity. Reopen picker → Quantity blurs and schedules setTouchedInput('quantity…') 200ms later. Select subrate #2 → onValidate runs synchronously before that 200ms timeout resolves, so Quantity is still untouched and the error is filtered again. The touched flag then flips true, but no validation re-runs (blur validation is off). Only on the next picker reopen + select (#3) does validation finally run with the flag already true, so the error appears. PR #92378 is the regression source because it replaced the prompt InteractionManager.runAfterInteractions(() => focus()) with TransitionTracker.runAfterTransitions(... requestIdleCallback(() => focus())), pushing the re-focus (and therefore the next blur that sets touched) later in the timeline — that extra delay is what shifted the error from appearing on the 2nd selection to the 3rd.

What changes do you think we should make in order to solve the problem?

We should make the Quantity field touched synchronously the moment we programmatically move focus to it after a subrate selection, instead of depending on the delayed blur from the next picker open. In IOURequestStepSubrate's onValueChange handler, right where we call textInputRef.current?.focus(), we should also mark quantity{pageIndex} as touched and trigger a revalidation through the form. The clean way is to expose a setTouched(inputID) (and a re-validate) on the existing FormRef and call it alongside the focus, so the subsequent synchronous onValidate on the next subrate change already sees the field as touched:

TransitionTracker.runAfterTransitions({
    callback: () => requestIdleCallback(() => textInputRef.current?.focus()),
    waitForUpcomingTransition: true,
});
formRef.current?.setTouched(`quantity${pageIndex}`); // touched is now set before the next validation

This is safe because it only marks the field the user has already interacted with (it was focused) as touched — it does not surface errors for fields the user never reached, and it does not change behavior for forms that don't opt into this call. It targets exactly the gap created by shouldValidateOnBlur={false} plus the deferred blur, restoring the intended "error shows on the very next subrate selection" behavior that PR #92378's QA step 8 expected.

What alternative solutions did you explore? (Optional)

Removing shouldValidateOnBlur={false} so the Quantity blur both touches and validates — rejected because blur-driven validation on this screen reintroduces the focus/keyboard timing issues that the shouldValidateOnBlur={false} and the TransitionTracker focus dance were added to avoid, and it would validate at moments (e.g. tabbing away) we don't want here.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Pujan92 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022069456754040220007

[aswin-s]

Please re-state the problem that we are trying to solve in this issue.

When a user selects a subrate for the first time, leaves the Quantity field empty, then opens the subrate picker again and picks a different subrate, no error is shown for the empty Quantity field — the error only appears on the third attempt. The expected behavior is that the quantity validation error appears immediately after the second subrate selection when the quantity is still empty.

What is the root cause of that problem?

In src/pages/iou/request/step/IOURequestStepSubrate.tsx, the FormProvider is configured with shouldValidateOnChange and shouldValidateOnBlur={false}. FormProvider only surfaces errors for inputs tracked in its internal touchedInputs ref — see FormProvider.tsx around line 237:

const touchedInputErrors = Object.fromEntries(
    Object.entries(validateErrors).filter(([inputID]) => touchedInputs.current[inputID])
);

When the user picks a subrate via the ValuePicker, the onInputChange callback registered by FormProvider fires. The critical execution order inside onInputChange is:

onInputChange: (value, key) => {
    const inputKey = key ?? inputID;
    setInputValues((prevState) => {
        const newState = { ...prevState, [inputKey]: value };
        if (shouldValidateOnChange) {
            onValidate(newState);   // <-- validation fires HERE, inside the state updater
        }
        return newState as Form;
    });
    // ...
    inputProps.onValueChange?.(value, inputKey);  // <-- page's onValueChange fires AFTER
},

onValidate is called inside the setInputValues state updater, which means it completes — and filters out untouched-input errors — before inputProps.onValueChange is ever called. At that moment, quantity${pageIndex} has never been marked as touched: the auto-focus via requestIdleCallback only focuses the native input element, it does not invoke the form's setTouchedInput for the quantity field. So the quantity error is generated by validate() but filtered out by touchedInputErrors, and the form stays silent.

Any attempt to call setTouchedInput (or equivalent) inside onValueChange is therefore too late for the validation pass that already ran inside the same onInputChange cycle. A second onValidate call must be triggered after the quantity field has been marked as touched.

By the third subrate selection the quantity field has been touched from a previous blur or submit cycle, which is why the error finally appears then.

What changes do you think we should make in order to solve the problem?

The fix belongs in src/pages/iou/request/step/IOURequestStepSubrate.tsx. The page needs to:

1. Keep a ref to the FormProvider's formRef (already passed via ref prop on FormProvider).
2. In the onValueChange handler for the subrate ValuePicker, after calling setSubrateValue(value as string), trigger a no-op onInputChange on the quantity field. This can be done by calling inputRef.current?.onInputChange(quantityValue, quantityInputID) — where quantityValue is the current quantity value (unchanged) — so that onInputChange fires a second time with quantity${pageIndex} already registered. But because onValidate runs inside the setInputValues updater, the quantity field must be marked as touched before that second onInputChange fires.

The cleanest path that requires no changes outside IOURequestStepSubrate.tsx:

Step 1 — store a ref to the quantity input's onInputChange using InputWrapper's existing ref plumbing, which exposes onInputChange on the input node.

Step 2 — in the subrate onValueChange, mark quantity as touched then re-trigger its onInputChange:

// Inside the ValuePicker's onValueChange for the subrate field:
onValueChange={(value) => {
    setSubrateValue(value as string);

    // Mark quantity as touched so the next onValidate pass surfaces its error.
    // We must do this before calling onInputChange (which calls onValidate internally).
    touchedInputs.current[`quantity${pageIndex}`] = true;

    // Re-fire onInputChange for the quantity field with its current value (no-op
    // in value, but triggers onValidate with quantity now in touchedInputs).
    quantityInputRef.current?.onInputChange(quantityValue, `quantity${pageIndex}`);
}}

However, touchedInputs is private to FormProvider. The correct public API to mark an input as touched is the onTouched event wired up in registerInput:

onTouched: (event) => {
    if (!inputProps.shouldSetTouchedOnBlurOnly) {
        setTouchedInput(inputID);
    }
    inputProps.onTouched?.(event);
},

So the actual implementation in IOURequestStepSubrate.tsx should:

1. Hold a ref to the quantity InputWrapper node: const quantityInputRef = useRef(null).
2. In the subrate ValuePicker's onValueChange:
   • Call setSubrateValue(value as string) as before.
   • Call quantityInputRef.current?.onTouched?.() to mark the quantity field as touched via the public form API.
   • Then call quantityInputRef.current?.onInputChange?.(quantityValue, \quantity${pageIndex}`)to trigger a freshonValidatepass that now includes the quantity field intouchedInputs`.

// Ref added near other state declarations:
const quantityInputRef = useRef<InputComponentBaseProps | null>(null);

// On the quantity InputWrapper, pass the ref:
<InputWrapper
    InputComponent={TextInput}
    inputID={`quantity${pageIndex}`}
    ref={quantityInputRef}
    // ...existing props
/>

// In the subrate ValuePicker's onValueChange:
onValueChange={(value) => {
    setSubrateValue(value as string);

    // Mark quantity as touched first, then re-trigger validation so the error
    // surfaces in the same interaction rather than requiring a third selection.
    if (quantityInputRef.current) {
        quantityInputRef.current.onTouched?.();
        quantityInputRef.current.onInputChange?.(quantityValue, `quantity${pageIndex}`);
    }
}}

This approach is safe because:

• onTouched is a no-op if shouldSetTouchedOnBlurOnly is set; the existing shouldValidateOnBlur={false} means that flag is not in play here.
• The second onInputChange call with the unchanged quantityValue causes no observable side-effect other than triggering onValidate with quantity now in touchedInputs, which is exactly the desired outcome.
• No changes to FormProvider or any shared component are needed.

What alternative solutions did you explore? (Optional)

Changing shouldValidateOnBlur to true on the FormProvider in IOURequestStepSubrate.tsx would also expose the error when the quantity field loses focus, but would not fix the case where the user never explicitly focuses and blurs the quantity field between subrate selections — which is exactly the scenario the issue describes.

Resetting touchedInputs on subrate change and relying on shouldValidateOnChange would clear already-shown errors on other fields, causing a regression for any user who had touched and then navigated away from other fields before changing the subrate.