[HOLD] [$250] IOU - Stuck with "Category no longer valid" on confirm page after changing to a valid category

[lanitochka17]

Held on #79741

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.4-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-3067/folder/13176877/41237353/1134638305
Email or phone of affected tester (no customers): josijdnosjoijdoijso@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Have a workspace.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create an expense with Advertising category in self DM.
4. Go to workspace settings > Categories.
5. Delete Advertising category.
6. Go back to self DM.
7. Click Submit it to someone.
8. Select the workspace with deleted Advertising category.
9. On confirm page, enter merchant.
10. Click Create expense.
11. Click Category.
12. Change to any category.
13. On confirm page, click Create expense.

Expected Result:

Expense can be submitted to the workspace chat because category is now valid.

Actual Result:

"Category no longer valid" persists on confirm page after changing to a valid category.
User is stuck on confirm page. The expense cannot be submitted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7053127_1768829916828.1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022014726313766705618
• Upwork Job ID: 2014726313766705618
• Last Price Increase: 2026-01-23

Issue Owner

Current Issue Owner: @

[melvin-bot]

Triggered auto assignment to @mallenexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[etCoderDysto]

Proposal

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

Stuck with "Category no longer valid" on confirm page after changing to a valid category

What is the root cause of that problem?

We are not clearing categoryOutOfPolicy formError when category changes here

App/src/components/MoneyRequestConfirmationList.tsx

Lines 447 to 450 in 7588135

	setFormError('');
	}
	// eslint-disable-next-line react-hooks/exhaustive-deps -- we don't want this effect to run if it's just setFormError that changes
	}, [isFocused, shouldDisplayFieldError, hasSmartScanFailed, didConfirmSplit, iouCategory, iouAttendees, policyCategories, currentUserPersonalDetails, policy?.isAttendeeTrackingEnabled]);

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

We should clear categoryOutOfPolicy error when there is change in category.

        if (formError === 'violations.categoryOutOfPolicy' && policyCategories && policyCategories[iouCategory] && policyCategories[iouCategory]?.enabled) {
            setFormError('');
        }

We can use clearFormErrors instead of setFormError.

        if (policyCategories && policyCategories[iouCategory] && policyCategories[iouCategory]?.enabled) {
            clearFormErrors(['violations.categoryOutOfPolicy']);
        }

What alternative solutions did you explore? (Optional)

We can create a separete useEffect like below and remove violations when only moving expense form DM to workspace

App/src/components/MoneyRequestConfirmationList.tsx

Lines 452 to 459 in 6fa8428

	useEffect(() => {
	// We want this effect to run only when the transaction is moving from Self DM to a expense chat
	if (!transactionID || !isDistanceRequest || !isMovingTransactionFromTrackExpense || !isPolicyExpenseChat) {
	return;
	}
	const errorKey = 'iou.error.invalidRate';
	const policyRates = DistanceRequestUtils.getMileageRates(policy);

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[yatin-italy]

Proposal

Restate the problem this issue is trying to solve.
After deleting a category and picking a valid one on the confirm page, submitting remains blocked with “Category no longer valid,” preventing expense submission.

What is the root cause of that problem?
formError stays set to violations.categoryOutOfPolicy; the submit handler exits early on this stale error instead of revalidating the current category (or other fields), so the corrected selection is never considered.

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

• Each submit attempt must validate only the current values.
• Old errors must never block submit after inputs are fixed.

In MoneyRequestConfirmationList, inside the confirm callback:

• Clear formError at the start.
• Remove early returns that depend on old formError.
• Always run validation on the latest data.

const confirm = useCallback(
    (paymentMethod: PaymentMethodType | undefined) => {
        // Always start clean; downstream checks will set errors if needed
        setFormError('');

        if (!!routeError || !transactionID) {
            return;
        }

        if (iouType === CONST.IOU.TYPE.INVOICE && !hasInvoicingDetails(policy)) {
            Navigation.navigate(
                ROUTES.MONEY_REQUEST_STEP_COMPANY_INFO.getRoute(
                    iouType,
                    transactionID,
                    reportID,
                    Navigation.getActiveRoute(),
                ),
            );
            return;
        }

        ...

        if (isEditingSplitBill && areRequiredFieldsEmpty(transaction)) {
            setDidConfirmSplit(true);
            setFormError('iou.error.genericSmartscanFailureMessage');
            return;
        }

        onConfirm?.(selectedParticipants);
    } else {
        if (!paymentMethod) {
            return;
        }

        if (isDelegateAccessRestricted) {
            showDelegateNoAccessModal();
            return;
        }

        Log.info(`[IOU] Sending money via: ${paymentMethod}`);
        onSendMoney?.(paymentMethod);
    }
},
[
    ...
],
);

What alternative solutions did you explore? (Optional)
None

[Eskalifer1]

Hi @ikevin127, seems like this is regression from #79050, especially this part:

App/src/components/MoneyRequestConfirmationList.tsx

Lines 446 to 452 in f6e1833

	// Reset the form error whenever the screen gains or loses focus
	// but preserve violation-related errors since those represent real validation issues
	// that can only be fixed by changing the underlying data
	if (!formError.startsWith(CONST.VIOLATIONS_PREFIX)) {
	setFormError('');
	return;
	}

[yatin-italy]

@Eskalifer1 @ikevin127 Agree it stems from #79050, but the blocker isn’t the focus reset. The submit flow sets violations.categoryOutOfPolicy once, and when the user picks a valid category we never clear/revalidate that error. The confirm handler bails early on the stale formError, so the new category is never considered. We should clear or recompute formError on category change (or at the start of submit) so only current values are validated. Thanks

[koko57]

Hi! Coming from #80192 as my problem has the same root cause. I agree with @yatin-italy - that

The submit flow sets violations.categoryOutOfPolicy once, and when the user picks a valid category we never clear/revalidate that error.

I also thought of clearing the error when submitting the for as @yatin-italy suggests, but it would mean showing the violations after changing the value. I see that some fields like merchant are cleared right after changing - I think it happens because of this condition

App/src/components/MoneyRequestConfirmationList.tsx

Lines 446 to 452 in f6e1833

	// Reset the form error whenever the screen gains or loses focus
	// but preserve violation-related errors since those represent real validation issues
	// that can only be fixed by changing the underlying data
	if (!formError.startsWith(CONST.VIOLATIONS_PREFIX)) {
	setFormError('');
	return;
	}

Merchant field violation is 'iou.error.invalidMerchant' so it passes the condition. But it means that we have very inconsistent error clearing. After introducing the fix we would still clear all the errors starting with 'iou' and these ones with 'violation' prefix would persist but won't block the confirmation. We unfortunately have these inconsistencies even for the single fields like categories or tags (look at the screenshots below).

also the current implementation clears the violation for merchant even if the field wasn't properly filled in.

Screen.Recording.2026-01-22.at.15.21.13.mp4

We could possibly clear all these violations on regaining focus, but I don't think it's the best option.

Yet another thing to consider: the validation flow is showing only one validation at a time - I had mentioned while working on tags:

So you only see the validation for the Category, Tags or Taxes field only when the merchant field and the subsequent are filled in. This is also imho not very user friendly. We should have all the errors shown at once.

Screen.Recording.2025-11-05.at.17.30.51.mp4

I think this whole validation flow should be rebuild - most importantly - the error being cleared when the correct value is provided. Showing all the violations at once can be done at the same time or not - up to your decision.

cc @cristipaval @parasharrajat

[parasharrajat]

We need backend changes to show all violations at a time. I also think we should do that....

@cristipaval What is the cost of making that change in the backend? Can you please discuss this internally and see if this is something we should do?

[ikevin127]

To double-check: is it or not a regression from my PR ? Just want to confirm as I have a follow-up PR open and can add the fix there if confirmed from my PR.

[koko57]

@parasharrajat no, it needs to be a FE fix - we don't send the transaction values to the BE every time we change it. We should deal with it locally. BE is only responsible for violations after the request for submitting the expense/creating one is sent.

@ikevin127 If I did it correctly I haven't noticed that reverting one particular commit from your PR fixed the issue. But I'll double check and let you know. But strangely - we worked on category field long time ago - so such problem should be catched much earlier. While working on Tags field that also use "violation." prefixed error, I also don't remember having a problem with that.

I already have an easy solution on my mind that I will test and if it works I'll post my findings.