Split expense-Second "Invalid amount" does not appear together with the first "Invalid amount"

[mitarachim]

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.3.74-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87920
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Run Onyx.merge('betas', ['newManualExpenseFlow']); in console.

1. Go to staging.new.expensify.com
2. Open DM with any user.
3. Click + > Split expense > Manual.
4. Without entering amount, click Split expense.

Expected Result:

The second "Invalid amount" error will appear together with the first "Invalid amount" error.

Actual Result:

The second "Invalid amount" error appears with delay after the first "Invalid amount" error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7154075_1778764824203.27.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #87920

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #87920 - "Feat: Manual expense flow UI refactor - r3" by @ChavdaSachin (High confidence)
Related Issues: #82586 (original issue this PR fixed)

Recommendation: REVERT

PR #87920 introduced the regression. It can be reverted to restore the pre-existing behavior. The bug only affects staging (the newManualExpenseFlow beta does not exist in production), making a clean revert the safest option.

Assigned: @ChavdaSachin (PR author), @ShridharGoel (approving reviewer), @puneetlath (approving reviewer) from highest-confidence causing PR only
Labels: DeployBlockerCash retained (App PR caused the issue); DeployBlocker not present so no change needed.

Detailed Analysis

Evidence

• The issue is reproducible only on staging and only when the newManualExpenseFlow beta is enabled (Onyx.merge('betas', ['newManualExpenseFlow'])). This feature does not exist in production, confirming it is staging-only and introduced by a recent PR.
• The melvin-bot already identified PR Feat: Manual expense flow UI refactor - r3 #87920 as the causing PR and it is unchecked in the StagingDeployCash checklist, consistent with being a known blocker.
• PR Feat: Manual expense flow UI refactor - r3 #87920 (Feat: Manual expense flow UI refactor - r3, merged 2026-05-13) is the only PR in the staging release that touches the split expense confirmation and validation code paths.

Verification

Affected files (all modified by PR #87920):

• src/components/MoneyRequestConfirmationList/hooks/useFormErrorManagement.ts — introduces useDebouncedState for formError, and uses the debounced value (debouncedFormError) for the split-type bottom error message.
• src/components/MoneyRequestConfirmationList/sections/AmountField.tsx — renders the inline amount error using the un-debounced formError directly.
• src/components/MoneyRequestConfirmationList/hooks/useConfirmationValidation.ts — validation logic changes for the new manual flow.

Confirmed: All three files are in the file list of PR #87920.

Root Cause

useFormErrorManagement uses useDebouncedState (300ms delay, defined in CONST.TIMING.USE_DEBOUNCED_STATE_DELAY) for formError. This produces two values:

• formError — updates immediately when setFormError is called.
• debouncedFormError — updates 300ms later.

In computeErrorMessage() (line 224-225 of useFormErrorManagement.ts), when isTypeSplit && !shouldShowReadOnlySplits, the bottom error message is driven by debouncedFormError rather than formError.

Meanwhile, the inline AmountField error text (amountFieldErrorText) reads formError directly and updates immediately.

When the user clicks "Split expense" without entering an amount:

1. validate() fires and returns {errorKey: 'common.error.invalidAmount'} (for a P2P split where iouAmount === 0 && isP2P is true) or {errorKey: 'common.error.fieldRequired'} (for the new manual flow when !transaction?.isAmountSet).
2. setFormError(result.errorKey) is called — formError updates immediately, causing the first inline "Invalid amount" error to appear on the AmountField at once.
3. 300ms later, debouncedFormError catches up and the bottom errorMessage on the confirmation footer is set — causing the second "Invalid amount" error to appear with a visible delay.

The two errors are showing the same condition through two different rendering paths with different timing, producing the described UX where the second error appears "with delay after the first."

[MelvinBot]

Proposal

What is the root cause of that problem?

For split expenses, the footer error message uses debouncedFormError (300ms debounce via useDebouncedState) while the inline AmountField error uses the raw formError which updates immediately.

When setFormError is called in confirmAction.ts:97, useDebouncedState updates formError instantly but delays debouncedFormError by 300ms. The split-specific code path in useFormErrorManagement.ts:224-225 reads debouncedFormError for the footer errorMessage, causing the 300ms stagger between the two error displays.

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

In useFormErrorManagement.ts:224-225, use the non-debounced formError instead of debouncedFormError for the split expense path in computeErrorMessage(), so both the inline field error and the footer error appear simultaneously.

What alternative solutions did you explore? (Optional)

An alternative would be to debounce the AmountField error as well so both errors appear together (both delayed). However, that would degrade UX by delaying all error feedback. Using the non-debounced value for the footer is simpler and makes both errors instant.

Investigation details

Data flow:

1. User clicks "Split expense" with no amount → confirmAction calls validate() → returns errorKey: 'common.error.fieldRequired'
2. setFormError('common.error.fieldRequired') is called at confirmAction.ts:97
3. useDebouncedState (delay = CONST.USE_DEBOUNCED_STATE_DELAY = 300ms) updates formError immediately, schedules debouncedFormError 300ms later
4. AmountField reads formError directly → shows inline error instantly (AmountField.tsx:96-104)
5. computeErrorMessage() for splits reads debouncedFormError → footer error appears 300ms later (useFormErrorManagement.ts:224-225)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.