Split - Two "Invalid amount" errors are shown

[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.41-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: #96228
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Open 1:1 DM.
3. Click + > Split expense > Manual.
4. Click Split.

Expected Result:

Only one "Invalid amount" error will be shown.

Actual Result:

Two "Invalid amount" errors are shown.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213110_1784601828695.10.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7213110

[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/8d58dcd5ac589966165fabfa7e2df98c03c16d928974935bc457e2df3f9c4a0c

[melvin-bot]

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

[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.

[MelvinBot]

Proposal

Root Cause

The Split confirmation screen renders the same common.error.invalidAmount error in two places at once:

1. Inline on the amount input via AmountField.tsx:105-112 — shouldShowAmountInvalidError sets the field's errorText.
2. At the bottom of the form (FormHelpMessage) via the split branch in useFormErrorManagement.ts:234-236.

computeErrorMessage already has a guard that suppresses the footer copy of invalidAmount precisely because the input surfaces it inline (useFormErrorManagement.ts:250-255) — but the isTypeSplit branch returns early at line 234 before that guard runs, so for splits the footer error is never suppressed and the message shows twice.

This is a regression from #96228 (feat: remove isNewManualExpenseFlowEnabled beta flag). Before the flag was removed, the split amount was not an editable inline input showing this error, so the footer error was the only one. Now the new manual flow renders the editable AmountField for splits too, making the footer copy a duplicate.

Recommended Fix

Let the split branch fall through the same inline-suppression the non-split path uses. Add the invalidAmount (and, for consistency, fieldRequired) guard inside the split branch in useFormErrorManagement.ts:234-236:

if (isTypeSplit && !shouldShowReadOnlySplits) {
    // These are surfaced inline on the editable amount input in the new manual flow, so don't repeat them here.
    if (!isDistanceRequest && (formError === 'common.error.invalidAmount' || formError === 'common.error.fieldRequired')) {
        return undefined;
    }
    return debouncedFormError ? translate(debouncedFormError) : undefined;
}

Keep the inline AmountField error as the primary surface (it's the intended one for the new flow); the footer copy is the redundant one.

Investigation details

• Error origin: useConfirmationValidation.validate() returns common.error.invalidAmount, and confirmAction.ts calls setFormError('common.error.invalidAmount') on Split.
• That single formError then drives both the inline AmountField render and the footer FormHelpMessage.
• Alternative considered: removing the inline error on AmountField instead — rejected, since the hook's own doc comments make clear the inline field is the intended primary surface and the footer is the redundant one.
• Line numbers verified against the merge commit 47f67e5 of feat: remove isNewManualExpenseFlowEnabled beta flag #96228.
• Confidence: high — deterministic UI logic; the dedupe intent is documented in-code. Best confirmed by manual repro (Split > Manual > Split with empty amount) or a component test.

---

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

[trjExpensify]

Can reproduce, we don't need the footer value. IOU P2P split flow though, so minor in priority. I vote demote.