Expense - (none) is populated in Merchant field after saving empty merchant

[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?: No
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): sjdojsodjniodnsjioj@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:

1. Go to staging.new.expensify.com
2. Log in with Gmail account.
3. Open self DM or DM with any user.
4. Click + > Create expense > Manual.
5. Enter amount > Next.
6. On confirm page, click Merchant.
7. Click Save without entering merchant.
8. Click Create expense.

Expected Result:

In Step 6, (none) will not be populated in Merchant field after saving empty merchant.

Actual Result:

In Step 6, (none) is populated in Merchant field after saving empty merchant.
In Step 7, expense cannot be created due to (none) in merchant field.

This issue also happens after removing merchant.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7153433_1778707520537.01.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: None

Recommendation: REVERT

PR #87920 introduced a regression in the old (non-new-manual-flow) expense creation path by changing setMoneyRequestMerchant to always set isMerchantSet: true, but the display logic in MerchantField.tsx now depends on isMerchantSet being false to suppress the "(none)" placeholder value from being shown to the user.

Assigned: @ChavdaSachin (PR author), @ShridharGoel and @puneetlath (approving reviewers)
Labels: DeployBlockerCash kept (App PR caused the issue). DeployBlocker removed — this is a frontend bug, no backend changes needed.

Detailed Analysis

Evidence

• The bug is staging-only (not reproducible in production), which is consistent with it being introduced by a PR in the current staging deploy.
• melvin-bot already assigned the issue to the author of PR Feat: Manual expense flow UI refactor - r3 #87920, which is listed in the StagingDeployCash checklist for version 9.3.74-0.
• PR Feat: Manual expense flow UI refactor - r3 #87920 modifies src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx and src/libs/actions/IOU/index.ts — the exact code paths involved in the merchant field behavior on the confirm page.

Verification

Affected file: src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx

PR #87920 modifies this file directly. The PR also modifies src/libs/actions/IOU/index.ts.

Confirmation that the PR modifies these files:

• src/components/MoneyRequestConfirmationList/sections/MerchantField.tsx — modified
• src/libs/actions/IOU/index.ts — modified

Root Cause

PR #87920 introduced a new isMerchantSet boolean flag on the Transaction type to distinguish between an empty merchant (field never touched) and a merchant explicitly set to the CONST.TRANSACTION.PARTIAL_TRANSACTION_MERCHANT placeholder "(none)" in the new manual expense flow.

Two interacting changes caused the regression:

1. setMoneyRequestMerchant now always sets isMerchantSet: true (in src/libs/actions/IOU/index.ts):

   Onyx.merge(..., {merchant, isMerchantSet: true});
   

2. IOURequestStepMerchant.tsx (old flow) saves empty merchant as PARTIAL_TRANSACTION_MERCHANT (i.e. "(none)"):

   setMoneyRequestMerchant(transactionID, newMerchant || CONST.TRANSACTION.PARTIAL_TRANSACTION_MERCHANT, true, ...)
   

   This is the step page users reach when they tap the Merchant row on the confirm page in the old flow.

3. MerchantField.tsx display logic now checks isMerchantSet to decide whether to show the value:

   const displayMerchantValue = !transaction?.isMerchantSet ? '' : merchantValue;
   

When the user opens the Merchant step page (old flow), clears the field, and taps Save:

• IOURequestStepMerchant calls setMoneyRequestMerchant(transactionID, '(none)', true, ...).
• This sets merchant = '(none)' and isMerchantSet = true.
• MerchantField then renders displayMerchantValue = '(none)' because isMerchantSet is true.
• The confirm page now shows "(none)" in the Merchant field, and attempting to submit fails with a validation error because "(none)" is treated as an invalid merchant value.

The isMerchantSet flag was designed for the new manual expense flow where clearing the text input calls clearMoneyRequestMerchant (which sets isMerchantSet: false). The old step-page flow was not updated to use clearMoneyRequestMerchant when the merchant is empty, so it falls into the broken path.