Repository navigation
[Due for payment 2026-08-27] Different unit is shown on table and Distance field after changing unit and adding new split #97403
Description
Activity
- addedDeployBlockerCashThis issue or pull request should block deploymentThis issue or pull request should block deployment
on Jul 29, 2026 - addedBugSomething is broken. Auto assigns a BugZero manager.Something is broken. Auto assigns a BugZero manager.
on Jul 29, 2026 While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/45372c8929a1775452dea95120b6e0049065fdcaf28b8f4f538139a5c996b93aYou have been assigned to this deploy blocker because you recently merged this PR: #92055
@ZhenjaHorbach you have been assigned to this deploy blocker because you authored the offending PR: #92055
💬 A slack conversation has been started in #expensify-open-source
github-actions commented
on Jul 29, 2026 on Jul 29, 2026 – with GitHub ActionsContributorMore 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:
- Identify the pull request that introduced this issue and revert it.
- Find someone who can quickly fix the issue.
- Fix the issue yourself.
🔍 Investigation Summary
Classification: Frontend bug
Causing PR: #92055 - "Fix bugs for selfDM splits feature" by @ZhenjaHorbach (High confidence)
Related Issues: NoneRecommendation: ROLL FORWARD (targeted fix)
#92055 is a large PR fixing 8 separate issues for the selfDM splits feature; reverting it would reintroduce all of those bugs. The regression here is a one-line unit-source change and is much safer to fix forward.
Assigned: @ZhenjaHorbach (PR author), @lakchote & @dmkt9 (approving reviewers) — already assigned by melvin-bot
Labels: No changes.DeployBlockerCashis correctly present (App/frontend deploy blocker) and is kept.DeployBlocker(Web) is not present and should not be added.📋 Detailed Analysis
Evidence
- The distance-split "Add split" flow is a new feature that does not exist in production, so this is staging-only and the cause must be a PR on the current
StagingDeployCashchecklist (Deploy Checklist: New Expensify 2026-07-29 #97375). Fix bugs for selfDM splits feature #92055 merged 2026-07-29 09:35 UTC and is on that checklist. - Fix bugs for selfDM splits feature #92055 directly rewrote the unit/rate derivation for distance splits in
src/libs/actions/IOU/SplitExpenseItems.ts(updateSplitExpenseAmountField), which is exactly the code path exercised by repro step 12 ("Enter amount on the new split and save the splits"). - The reported symptom — merchant flips to the new unit only after entering an amount and saving, while the Distance field keeps the old unit — matches precisely: the merchant string is recomputed in
updateSplitExpenseAmountField, whereas the Distance field is recomputed independently at render time.
Verification
- Bug area: distance-split merchant string vs. the Distance/rate field on the split details page.
- Distance field (shows OLD unit):
MoneyRequestView.tsx#L584-L612callsDistanceRequestUtils.getRate(...)with the defaultuseTransactionDistanceUnit = true. getRatecontract (the intended protection):DistanceRequestUtils.ts#L528-L575—getDistanceUnitreturnstransaction.comment.customUnit.distanceUnitfirst, deliberately "to prevent policy changes modifying existing transactions" (its own doc comment).- Merchant string (shows NEW unit):
SplitExpenseItems.ts#L673-L707— confirmed modified by Fix bugs for selfDM splits feature #92055. - The merchant quantity update preserves
distanceUnit:updateSplitExpenseDistanceFromAmountSplitExpenseItems.ts#L55-L80— it spreadsexistingCustomUnitand only overwritesquantity, sodistanceUnitstays the OLD unit while the merchant is built from a differentunitargument.
Root Cause
Before #92055,
updateSplitExpenseAmountFieldderived the merchantunitfromresolveSplitMileageRate(...)(i.e.getRate), which respects the transaction's storeddistanceUnit(the unit at creation time = old unit). The removed line was:const {unit, rate: mileageRateValue} = mileageRate;
#92055 replaced this so the
unitnow comes fromgetRateByCustomUnitRateID(...)(the split's currently-selected policy rate):const splitSelectedRate = DistanceRequestUtils.getRateByCustomUnitRateID({policy, customUnitRateID: splitRateID}) ?? DistanceRequestUtils.getEnabledRateByCustomUnitRateIDFromAnyPolicy(splitRateID, policies); ... const unit = useSplitSelectedRate ? (splitSelectedRate?.unit ?? mileageRate.unit) : mileageRate.unit;
getRateByCustomUnitRateIDreads the unit straight off the current policy rate attributes (kmafter the workspace unit was changed in step 7), bypassing the "use the transaction's storeddistanceUnit" protection thatgetRateprovides. So the merchant string is now built withkm(new), while:- the split's
customUnit.distanceUnitis left atmi(old), and - the Distance field still renders via
getRate(oldmi).
Result: merchant/table shows
km, Distance field showsmi— the exact inconsistency reported. This is purely a frontend derivation bug inExpensify/App; the backend is not involved.Suggested fix direction (for the assignees): keep taking the rate value from
splitSelectedRate, but deriveunitfrom the transaction's storeddistanceUnit(asgetRate/mileageRatealready does) so the merchant matches the Distance field — matching the issue's Expected Result. Alternatively, if adopting the new unit is intended, also updatecustomUnit.distanceUnitand convertquantityso both surfaces agree; the current half-updated state is the bug.- The distance-split "Add split" flow is a new feature that does not exist in production, so this is staging-only and the cause must be a PR on the current
4 remaining items
- addedReviewingHas a PR in reviewHas a PR in reviewWeeklyKSv2KSv2and removedDailyKSv2KSv2
on Jul 30, 2026 ⚠️ Looks like this issue was linked to a Deploy Blocker hereIf you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
⚠️ Looks like this issue was linked to a Deploy Blocker hereIf you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
- addedDailyKSv2KSv2and removedReviewingHas a PR in reviewHas a PR in reviewWeeklyKSv2KSv2
on Aug 20, 2026 - changed the title
[-]Different unit is shown on table and Distance field after changing unit and adding new split[/-][+][Due for payment 2026-08-27] Different unit is shown on table and Distance field after changing unit and adding new split[/+]on Aug 20, 2026 The solution for this issue has been 🚀 deployed to production 🚀 in version 9.4.56-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2026-08-27. 🎊
The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]. If no checklist is needed for this issue, you can click: [no checklist button]
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
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.46-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: #92055
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@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:
→ Merchant field for the new split shows the new unit.
→ Distance field still shows the old unit.
Expected Result:
In Step 12, merchant field for the new split should show the old unit.
Actual Result:
In Step 12, merchant field for the new split shows the new unit.
In Step 13, Distance field on the split details page shows the old unit.
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug7221277_1785359614461.6.mp4
View all open jobs on GitHub
Issue Owner
Current Issue Owner: @ZhenjaHorbach