Expense - Inline tax amount does not update correctly when amount is entered

[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.0-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: #92059
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@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:

• Run Onyx.merge('betas', ['newManualExpenseFlow']); in console.
• Enable Taxes in workspace settings.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Create expense > Manual.
4. Select 5% tax rate.
5. Enter 1 on Amount field.
   → Tax amount shows 0.00 instead of 0.05.
6. Add 0 so amount becomes 10
   → Tax amount shows 0.05 instead of 0.48.
7. Remove 0 so amount becomes 1.
   → Tax amount shows 0.48 instead of 0.05.
8. Clear amount field.
   → Tax amount shows 0.05 instead of 0.

Expected Result:

When amount is entered, inline tax amount field should update accordingly.

Actual Result:

In Step 5, after entering amount 1, tax amount shows 0.00 instead of 0.05.
In Step 6, after entering amount 10, tax amount shows 0.05 instead of 0.48.
In Step 7, after removing 0 to become 1, tax amount shows 0.48 instead of 0.05.
In Step 8, after clearing amount, tax amount shows 0.05 instead of 0.
It seems that inline tax amount field updates one step late.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7172890_1780683879287.10.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7172890

Issue Owner

Current Issue Owner: @dukenv0307

[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/0a9e34da684d472952e8e1cdee39f251703a972c6797c31f3f8881b19009a2bc

[melvin-bot]

@JS00001 recently merged #92059, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @youssef-lr (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

Proposal

What is the root cause of that problem?

The inline tax amount field lags one step behind the expense amount because of a remount-vs-persist race introduced in #92059.

The inline tax field is a NumberWithSymbolForm whose displayed value is only initialized from its value prop at mount (NumberWithSymbolForm.tsx:210). Its only prop→state sync effect (NumberWithSymbolForm.tsx:223-230) only fires when the value resets to empty — non-empty external updates are ignored.

To push a new value in, TaxFields keys the form on the expense amount (TaxFields.tsx:62, used as key at L115), forcing a remount on every keystroke. But the value it mounts with is the persisted transaction.taxAmount (TaxFields.tsx:55-59), and that persisted value is only recomputed after render, in a useEffect in TaxController.tsx:51-56.

So on each amount change the field remounts and reads the tax that belongs to the previous amount, exactly matching the reported "one step late" symptom (enter 1 → shows 0.00; enter 10 → shows 0.05; back to 1 → shows 0.48; clear → shows 0.05).

Step-by-step trace

1. User types a new expense amount → transaction.amount updates in Onyx synchronously.
2. TaxFields re-renders → taxAmountInputKey (which includes taxSlice?.amount) changes → NumberWithSymbolForm remounts.
3. On remount, its display state initializes from value={taxAmountInput}, derived from getTaxAmount(transaction) = the persisted transaction.taxAmount — still the value for the previous amount, because TaxController's effect hasn't run yet.
4. After render, TaxController persists the correct new tax amount — but the form does not remount again (the key only changes on the next amount keystroke), so the display stays frozen at the stale value until the next change.

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

Make the inline tax field reflect external value changes instead of relying on a remount that races persistence. Concretely:

1. In NumberWithSymbolForm, extend the sync effect at NumberWithSymbolForm.tsx:223-230 so that when the field is not focused, its internal currentNumber syncs to the incoming value prop (not just on the empty‑reset case). Gating on "not focused" avoids cursor jumps while the user is typing and preserves manual tax edits.
2. Remove taxSlice?.amount from taxAmountInputKey (TaxFields.tsx:62) so the field no longer remounts on every amount change — the prop sync from step 1 now drives the update, eliminating the race.

What alternative solutions did you explore? (Optional)

Keep the remount key but feed the field the freshly calculated tax (getCalculatedTaxAmount, already computed as maxTaxAmount at TaxFields.tsx:66) instead of the lagging persisted transaction.taxAmount. This is smaller but has a caveat: on a remount triggered for other reasons it would overwrite a user's manual tax edit with the recalculated max, so the prop-sync approach above is preferred.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92818) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[godzillaxbox19982014-lgtm]

Proposal

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

Expense - Inline tax amount does not update correctly when amount is entered

What is the root cause of that problem?

I traced this to the path that handles workspace name, expense report, newManualExpenseFlow:

• src/libs/actions/IOU/SplitTransactionUpdate.ts:751 (workspaceExpenseReportID): const workspaceExpenseReportID = isConfirmedWorkspaceTransaction ? (workspaceChatReport?.iouReportID ?? splitTransaction?.reportID) : undefined;
• src/libs/actions/IOU/SplitTransactionUpdate.ts:754 (iouReportID): const iouReportID = workspaceExpenseReportID ?? splitExpense?.reportID ?? transactionThreadReport?.parentReportID;
• src/libs/actions/IOU/SplitTransactionUpdate.ts:757 (newTransactionReportID): const newTransactionReportID = isSelfDMPerDiemSplit ? CONST.REPORT.UNREPORTED_REPORT_ID : (workspaceExpenseReportID ?? splitExpense?.reportID);
• The local evidence matches this recurring failure shape: optimistic transaction/report data is written to one Onyx key but the visible list reads another derived key. Here, src/libs/actions/IOU/SplitTransactionUpdate.ts:751 and src/libs/actions/IOU/SplitTransactionUpdate.ts:754 do not agree on the same workspace name, expense report, newManualExpenseFlow value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/libs/actions/IOU/SplitTransactionUpdate.ts:751 to derive workspace name, expense report, newManualExpenseFlow from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/libs/actions/IOU/SplitTransactionUpdate.ts:754; that follows the safer family move to align optimistic/success/failure data with the selector consumed by the screen, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Reports, Expenses, IOU, Transactions surface and avoid changing payment actions, personal/deleted policies.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ReportUtils*.ts for the exact issue flow: Expense - Inline tax amount does not update correctly when amount is entered.
2. Cover the counter-case near src/libs/actions/IOU/SplitTransactionUpdate.ts:751 so valid existing workspace name, expense report, newManualExpenseFlow behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep workspace name, expense report, newManualExpenseFlow consistent at the first read/write boundary shown above.