Expense - Merchant cannot be cleared by inline editing

[lanitochka17]

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.62-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: #83127
Email or phone of affected tester (no customers): sdsodijnosdjoij@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. Go to self DM.
3. Create an expense.
4. Go to Spend > All expenses.
5. Click Merchant field.
6. Clear merchant field and hit Enter.

Expected Result:

Merchant can be cleared (we can clear merchant field in unreported expense).

Actual Result:

Merchant cannot be cleared by inline editing.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7136969_1776977876597.12.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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: #83127 - "Adds inline editing to transaction table cells (date, merchant, description, category, amount)" by @mohammadjafarinejad (High confidence)
Related Issues: None

Recommendation: REVERT

PR #83127 introduced a hard guard in editTransactionMerchantInline that silently blocks saving an empty merchant string, which prevents users from clearing the merchant field via inline editing. Reverting this PR would restore the previous behavior where merchants can be cleared on unreported expenses.

Assigned: @mohammadjafarinejad (PR author), @ahmedGaber93 (approving reviewer), @puneetlath (approving reviewer) from PR #83127
Labels: DeployBlockerCash kept (frontend App PR is the cause). No label changes required — DeployBlocker is not present.

Detailed Analysis

Evidence

• The issue reports that clearing the merchant field and pressing Enter does not save the empty value; the field reverts to its original non-empty value.
• The bug is staging-only (version 9.3.62-0) and is described as a new feature that does not exist in production, which aligns exactly with PR feat: Add inline editing for tables on desktop #83127 being the first PR to introduce inline editing of merchant on the transaction table.
• melvin-bot already flagged PR feat: Add inline editing for tables on desktop #83127 as the suspect in the first comment on this issue.
• PR feat: Add inline editing for tables on desktop #83127 is present in the current StagingDeployCash checklist (item 14 in chronological order).

Verification

Affected file: /home/runner/_work/App/App/src/libs/actions/TransactionInlineEdit.ts

PR #83127 directly adds this file (src/libs/actions/TransactionInlineEdit.ts) as a new file. The problematic code is in editTransactionMerchantInline (lines 192–204):

function editTransactionMerchantInline(params: TransactionInlineEditParams, newMerchant: string) {
    // Merchant must be a non-empty string. An empty merchant is not a valid
    // state and the IOU action would save it as a blank row label.
    if (!newMerchant.trim()) {
        return;  // <-- silently blocks clearing the field
    }
    ...
}

Confirmation the PR touches the affected code:

• src/libs/actions/TransactionInlineEdit.ts — newly introduced by PR feat: Add inline editing for tables on desktop #83127, contains the merchant guard
• src/components/TransactionItemRow/DataCells/MerchantCell.tsx — newly introduced by PR feat: Add inline editing for tables on desktop #83127, wires onSave to editTransactionMerchantInline
• src/components/Table/EditableCell/useInlineEditState.ts — introduced by PR feat: Add inline editing for tables on desktop #83127; save() calls onSave?.(localValue) only when localValue !== value, which correctly allows an empty value through — the block is upstream in editTransactionMerchantInline

The underlying updateMoneyRequestMerchant in src/libs/actions/IOU/UpdateMoneyRequest.ts accepts any string including empty strings and was not modified by PR #83127, confirming the backend supports clearing merchants. The guard in the new inline-edit action layer is the sole reason clearing fails.

Root Cause

editTransactionMerchantInline adds an early-return guard (if (!newMerchant.trim()) return) to prevent saving an empty merchant. However, for unreported expenses (self-DM), clearing the merchant is a supported and expected operation — the existing updateMoneyRequestMerchant action (which the old non-inline editing path uses) accepts empty strings without issue. The guard is too broad: it fires for all transaction types, including unreported expenses where the user should be allowed to clear the field.