Expense - "This field is required" error is cleared after editing different field with error

[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): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

1. Open the staging.new.expensify.com website.
2. Start a manual expense creation flow.
3. Add a "Merchant" and "Category" but leave amount field empty.
4. Clear the "Date" field.
5. Click on "Create Expense"
6. Note that a "This field is required" error appears on "Amount" and "Date"
7. Add an amount.
8. Note that error is also cleared on "Date" field.

Expected Result:

"This field is required" error should still be visible on empty field after another invalid field is edited.

Actual Result:

"This field is required" error disappears after editing another field with error.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213118_1784603256396.Required.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7213118

[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/5b5683eb5eb4c8b3bc8913755dd6c61f9033aee48a678cdc06bf93e2613eec9b

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96228 - "feat: remove isNewManualExpenseFlowEnabled beta flag" by @thelullabyy (High confidence)
Related Issues: This regression only exists in the new manual expense flow, which is the same feature that was previously reverted as #94134.

Recommendation: ROLL FORWARD (targeted fix)

The root cause is a small, self-contained logic bug: the Amount and Date inline "This field is required" errors are both driven by a single shared formError state, so clearing it for one field wipes it for the other. Reverting #96228 would re-hide the entire new manual expense flow (a beta-flag removal that re-lands ~18 already-fixed and QA'd blockers), which is far more disruptive than the targeted one-line-area fix described below.

Assigned: @thelullabyy (PR author), @ikevin127, @joekaufmanexpensify, @puneetlath (approving reviewers) from the causing PR.
Labels: No label changes. DeployBlockerCash is kept — this is a frontend bug caused by an App PR, and the App deploy should remain blocked. No DeployBlocker (web) label was present.

📋 Detailed Analysis

Evidence

• The bug is staging-only / doesn't exist in prod because the entire new manual expense flow is gated behind the isNewManualExpenseFlowEnabled beta flag. PR feat: remove isNewManualExpenseFlowEnabled beta flag #96228 removed that flag, exposing this code path to everyone on staging. The commit history of the affected file confirms this: the most recent commit is feat: remove isNewManualExpenseFlowEnabled beta flag, immediately preceded by an earlier Revert "feat: remove isNewManualExpenseFlowEnabled beta flag" (the reverted attempt feat: remove isNewManualExpenseFlowEnabled beta flag #94134).
• PR feat: remove isNewManualExpenseFlowEnabled beta flag #96228 directly modifies all of the files involved in the buggy behavior: sections/AmountField.tsx, sections/DateField.tsx, and hooks/useFormErrorManagement.ts.
• The symptom (typing a valid Amount clears the still-empty Date field's required error) maps exactly to the shared-state clearing logic below.

Verification

Affected files (all modified by #96228):

• AmountField.tsx — line 277 clears the shared error.
• DateField.tsx — line 68 derives the Date inline error from the same shared state.
• useFormErrorManagement.ts — clearFormErrors clears the single formError value.

Root Cause

Both the Amount and Date inline errors are rendered off of one shared formError string rather than per-field error state:

• AmountField.tsx:104 → shouldShowAmountRequiredError = formError === 'common.error.fieldRequired' && !transactionSlice?.isAmountSet
• DateField.tsx:68 → inlineDateErrorText = formError === 'common.error.fieldRequired' && createdMissing

Both fields show "This field is required" whenever formError === 'common.error.fieldRequired', each additionally gated by its own "am I still missing?" check (!isAmountSet for amount, createdMissing for date). When the user types a valid amount, handleAmountChange runs and hits:

• AmountField.tsx:277 → clearFormErrors(['common.error.invalidAmount', 'common.error.fieldRequired'])

which calls clearFormErrors in the hook:

const clearFormErrors = (errors: string[]) => {
    if (!errors.includes(formError)) {
        return;
    }
    setFormError('');  // wipes the SINGLE shared formError
};

(useFormErrorManagement.ts:148-154)

Because formError is currently 'common.error.fieldRequired' (shared by both fields), setFormError('') clears it globally. The Date field, still empty, immediately loses its inline error because its display condition formError === 'common.error.fieldRequired' is no longer true — even though createdMissing is still true. The same coupling exists on the DateField side: handleDateChange at DateField.tsx:79-81 also calls clearFormErrors(['common.error.fieldRequired']) when a date is entered, which would symmetrically clear a still-present Amount required error.

Note the validation source of truth is fine — useConfirmationValidation.ts:203-205 still blocks confirmation while the date is missing (shouldShowDate && !isReadOnly && isCreatedMissing(transaction)). So this is purely an inline error-display regression: the required-error message disappears from the Date field, but a subsequent "Create Expense" would still be blocked. The user simply loses the visual cue about which field is still invalid.

Suggested fix direction (for the author)

Don't drive two independent inline field errors off one shared common.error.fieldRequired string. Either:

1. Track required-field errors per field (e.g. separate amount vs. date required flags), so clearing one doesn't clear the other; or
2. In clearFormErrors, before clearing common.error.fieldRequired, re-check whether any other required field is still missing (amount missing OR date missing) and, if so, keep/re-set the shared error instead of blanking it.

Option 1 is cleaner and avoids the symmetric coupling in both handleAmountChange and handleDateChange.