After multi edit expenses without changing tag, Tag disappears and shows system message

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.73-3
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #97951
Email or phone of affected tester (no customers): jsdoijnodsdisojo@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:

Precondition:

• Enable Tags.
• Create at least one tag.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses with tag.
4. Open the report.
5. Bulk select the expenses.
6. Click dropdown button > Edit multiple.
7. Click Category and select a category.
8. Click Tag and select the same tag from Step 3.
9. Click Tag and deselect tag.
10. Click Save.
11. Open any expense.

Expected Result:

In Step 10, after saving the edit without changing tag, Tag field on the table will not disappear.

In Step 11, expense details page will not show tag edit system message.

Actual Result:

In Step 10, after saving the edit without changing tag, Tag field on the table disappears and reappears.

In Step 11, expense details page shows tag edit system message when no changes are made to tag.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7253593_1788796701758.11.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @dilshodmackbook-sketch

[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/57e4b05f4924781eb06b7e5c589f9269cf97d59f809e5a64971843335d02c847

[melvin-bot]

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

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

[melvin-bot]

@francoisl @NikkiWines @sobitneupane you have been assigned to this deploy blocker because you reviewed the offending PR: #97951

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #97951 - "Fix: preserve untouched tag levels when bulk-editing a single tag level" by @MelvinBot (High confidence)
Related Issues: #97356 (the issue PR #97951 was fixing)

Recommendation: REVERT

PR #97951 is the only PR in this release that touches the bulk-edit tag code at all, and the regression is in the mechanism the PR introduced (per-level tag "edit intents" that force a tag change even when the resolved tag is empty). Reverting is clean — no commit has landed on any of the PR's files since it merged — and it only re-exposes the non-blocking bug in #97356.

Assigned: @sobitneupane, @NikkiWines, @francoisl (approving reviewers of #97951) — already assigned by melvin-bot. The PR author is a bot, so there is no human author to add.
Labels: No changes. DeployBlockerCash is correct and stays (App-side regression). DeployBlocker was never applied, so there is nothing to remove.

📋 Detailed Analysis

Evidence

• Reproducible on staging, not on production, so the cause is in this release.
• Scoping the release to the affected code path is unambiguous. Comparing commit history on the two branches for the bulk-edit files:
  • src/libs/actions/IOU/BulkEdit.ts — newest commit on production is 05b93fb8 (2026-08-29, bulk-edit attendees). On staging there are four newer commits, all from claude-fixBulkEditTagLevelWipe (PR Fix: preserve untouched tag levels when bulk-editing a single tag level #97951): f6d65c77 "Fix: preserve untouched tag levels when bulk-editing a single level", 6322557c "Apply bulk tag clear-to-empty edits instead of dropping them", 917fb208 "De-scope tag deselection…", 8767e248.
  • src/pages/Search/SearchEditMultiple/SearchEditMultipleTagPage.tsx — newest commit on production is dd303981 (2026-07-03, a formatting pass). On staging there are four newer commits, again all from PR Fix: preserve untouched tag levels when bulk-editing a single tag level #97951, ending with 0ec89319 "Record an empty tag intent when deselecting so the cleared level is not re-applied".
• No other PR on the StagingDeployCash checklist (Deploy Checklist: New Expensify 2026-09-07 #100479) touches BulkEdit.ts, SearchEditMultiple*, TagsOptionsListUtils, or TagPicker.
• The commit titles show the deselect semantics were flip-flopped three times inside this one PR (apply clear-to-empty → de-scope deselection → record an empty intent on deselect), which is where the regression landed.
• The repro steps corroborate the mechanism exactly: step 7 (pick a category) is required. Without another changed field the payload would be empty and the whole expense is skipped by the "Skip if no updates" guard, so nothing would happen at all. The category edit is what keeps the write alive so the phantom tag change can ride along in the optimistic data.

Verification

Affected files, at PR #97951's merge commit 029953ab:

1. SearchEditMultipleTagPage.tsx#L56-L73 — records '' as the tag intent when the user deselects. Added by 0ec89319, part of Fix: preserve untouched tag levels when bulk-editing a single tag level #97951.
2. BulkEdit.ts#L319-L346 — the new editedTagIndexes branch. Added by Fix: preserve untouched tag levels when bulk-editing a single tag level #97951.
3. BulkEdit.ts#L385-L387 — pre-existing truthiness guard that the new branch now collides with.
4. SearchEditMultiplePage.tsx#L211 — passes the draft's bulkEditTagChanges into apply time. Added by Fix: preserve untouched tag levels when bulk-editing a single tag level #97951.

All four are in the diff of #97951, which changes src/libs/actions/IOU/BulkEdit.ts, both SearchEditMultiple pages, src/types/onyx/Transaction.ts and src/libs/DebugUtils.ts.

Root Cause

Walking the repro with one tag list and two expenses that both already have TagA:

1. Step 8 (select TagA). The picker seeds currentTag from the draft, not from the expenses' shared tag: const currentTag = getTagArrayFromName(draftTag ?? '').at(tagListIndex) ?? ''. On first open the draft has no tag, so currentTag is '' and picking TagA reads as a fresh selection. Draft becomes tag: 'TagA', bulkEditTagChanges: {0: 'TagA'}. (Note transactionTag one line above does fall back to the common tag, so the two are seeded inconsistently.)
2. Step 9 (deselect TagA). Now currentTag === 'TagA', so isDeselecting is true and the intent is recorded as an empty string: {[tagListIndex]: isDeselecting ? '' : selectedTagName}. Draft becomes tag: '', bulkEditTagChanges: {0: ''}.
3. Step 10 (Save). draftTransaction.tag is '', so changes.tag is never set. Before Fix: preserve untouched tag levels when bulk-editing a single tag level #97951 the apply-time guard was if (changes.tag && …), so the round trip was a no-op. Fix: preserve untouched tag levels when bulk-editing a single tag level #97951 changed it to if ((changes.tag || editedTagIndexes.length > 0) && …), so the empty intent now forces the branch.
4. Inside the branch, getUpdatedTransactionTag is replayed with selectedTagName: '' and currentTag: ''; isSelectedTag is therefore true and it takes the deselect path. For a single tag list insertTagIntoTransactionTagsString returns the raw tag when hasMultipleTagLists is false, so reconstructedTag is '' and transactionChanges.tag = ''. It survives removeUnchangedBulkEditFields because '' !== 'TagA'.
5. The divergence. The API payload is built with a truthiness guard — if (transactionChanges.tag) { updates.tag = transactionChanges.tag; } — so the empty tag is silently dropped and UpdateMoneyRequest never learns about the clear. But the optimistic Onyx data is built from transactionChanges, not from updates: getUpdatedTransaction and buildOptimisticModifiedExpenseReportAction both receive tag: ''.

That divergence is precisely the two reported symptoms: the optimistic update clears the tag (Tag column disappears) and then the server response, which was never told about any tag change, restores it (reappears) — while the optimistic MODIFIED_EXPENSE "changed the tag" action stays behind as the spurious system message.

The unit tests added in #97951 do not catch this because every deselect case they cover is a multi-level tag where the reconstructed tag is still non-empty ('CostCenterA', 'CostCenterB'), which passes the truthiness guard. The single-level case, where the tag reconstructs to '', is untested.

If the team prefers to roll forward instead

Two changes are needed together, which is part of why a revert is the safer call under deploy-blocker time pressure:

1. Make the API payload agree with the optimistic data: if (transactionChanges.tag !== undefined) at BulkEdit.ts#L385, matching how category is already handled one branch above. Without this, any bulk tag clear is optimistic-only.
2. Decide the product behavior for "select then deselect the same tag" and seed currentTag from the common tag (like transactionTag on the line above) so the picker doesn't present an already-shared tag as unselected in the first place.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-19 Build API payloads and optimistic data from the same guard
• Condition: When an action builds both an API payload and optimistic Onyx data from one changes object, guard clearable fields with !== undefined, never with truthiness. A truthiness guard drops '', 0 and false, so a clear is applied optimistically but never sent to the server, and the UI silently rolls back on the server response.
• Why: In bulk edit, transactionChanges.tag = '' reached the optimistic transaction and the optimistic MODIFIED_EXPENSE action, but if (transactionChanges.tag) kept it out of the updates payload. The tag visibly cleared, the server restored it, and a phantom "changed the tag" system message was left behind (this issue). The same function still guards merchant, created, currency, comment and taxCode by truthiness while category, amount, billable and reimbursable correctly use !== undefined, so the latent bug exists for clearing a merchant or description too.
• Search pattern: in src/libs/actions/**, grep -nE 'if \(\w*[Cc]hanges\.\w+\) \{' -A2 and flag any hit whose body assigns into an API params/updates object for a field typed string | undefined that is also passed to a getUpdated*/buildOptimistic* helper.
• Offending code (❌):

  App/src/libs/actions/IOU/BulkEdit.ts

  Lines 385 to 387 in 029953a

  	if (transactionChanges.tag) {
  	updates.tag = transactionChanges.tag;
  	}

• Correct form already in the same function (✅):

  App/src/libs/actions/IOU/BulkEdit.ts

  Lines 382 to 384 in 029953a

  	if (transactionChanges.category !== undefined) {
  	updates.category = transactionChanges.category;
  	}

The full rule file, with the ❌/✅ code inline in App's coding-standards format, would go in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.

[MelvinBot]

🤖 Deploy blocker verdict

Causing PR: Expensify/App#97951 — high confidence. Recommendation: revert.

It is the only PR in this release that touches the bulk-edit tag path, and the regression is in the mechanism it added. Deselecting a tag records an empty-string edit intent, which now forces the tag branch at src/libs/actions/IOU/BulkEdit.ts:320. The empty tag reaches the optimistic data but is dropped from the API payload by the truthiness guard at BulkEdit.ts:385 — so the tag clears locally, the server restores it, and the optimistic MODIFIED_EXPENSE action is left behind as the phantom system message. That is exactly the reported "disappears and reappears + spurious system message."

The full root-cause walkthrough, branch-history evidence, roll-forward alternative, and a suggested code review rule are in my detailed comment above.

One caveat on verification: I confirmed the offending code is present in the release, but I could not reproduce the flow in a browser — the test session never rendered the app (blank page, zero DOM nodes) while the dev server and bundles were healthy, so this was an infra failure rather than an App one. The conclusion rests on code and commit-history evidence only, not on an in-app repro.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

---

view run · view recording