Skip to content

[Due for payment 2026-08-27] Different unit is shown on table and Distance field after changing unit and adding new split #97403

Description

@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.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:

  • Enable Distance rates.
  1. Go to staging.new.expensify.com
  2. Go to workspace chat.
  3. Create a distance expense.
  4. Open the expense.
  5. Click More > Split > Save.
  6. Go to workspace settings > Distance rates.
  7. Click Settings > Unit > change to Kilometer.
  8. Go back to workspace chat.
  9. Open any split.
  10. Click Amount.
  11. Click Add split.
  12. Enter amount on the new split and save the splits.
    → Merchant field for the new split shows the new unit.
  13. Open the new split.
    → 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:

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

Screenshots/Videos

Bug7221277_1785359614461.6.mp4

View all open jobs on GitHub

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

Issue OwnerCurrent Issue Owner: @ZhenjaHorbach

Activity

  1. added
    BugSomething is broken. Auto assigns a BugZero manager.
    on Jul 29, 2026
  2. applause-bot commented on Jul 29, 2026

    @applause-bot
    Author

    While Applause doesn't embed attachments for this bug, here are the links for quick view:
    https://platform.applause.com/services/links/v1/external/45372c8929a1775452dea95120b6e0049065fdcaf28b8f4f538139a5c996b93a

  3. melvin-bot commented on Jul 29, 2026

    @melvin-bot

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

  4. melvin-bot commented on Jul 29, 2026

    @melvin-bot

    @lakchote @dmkt9 you have been assigned to this deploy blocker because you reviewed the offending PR: #92055

  5. melvin-bot commented on Jul 29, 2026

    @melvin-bot

    @ZhenjaHorbach you have been assigned to this deploy blocker because you authored the offending PR: #92055

  6. melvin-bot commented on Jul 29, 2026

    @melvin-bot

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

  7. github-actions commented on Jul 29, 2026

    @github-actions
    Contributor

    👋 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.
  8. MelvinBot commented on Jul 29, 2026

    @MelvinBot
    Contributor

    🔍 Investigation Summary

    Classification: Frontend bug
    Causing PR: #92055 - "Fix bugs for selfDM splits feature" by @ZhenjaHorbach (High confidence)
    Related Issues: None

    Recommendation: 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. DeployBlockerCash is 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 StagingDeployCash checklist (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

    Root Cause

    Before #92055, updateSplitExpenseAmountField derived the merchant unit from resolveSplitMileageRate(...) (i.e. getRate), which respects the transaction's stored distanceUnit (the unit at creation time = old unit). The removed line was:

    const {unit, rate: mileageRateValue} = mileageRate;

    #92055 replaced this so the unit now comes from getRateByCustomUnitRateID(...) (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;

    getRateByCustomUnitRateID reads the unit straight off the current policy rate attributes (km after the workspace unit was changed in step 7), bypassing the "use the transaction's stored distanceUnit" protection that getRate provides. So the merchant string is now built with km (new), while:

    • the split's customUnit.distanceUnit is left at mi (old), and
    • the Distance field still renders via getRate (old mi).

    Result: merchant/table shows km, Distance field shows mi — the exact inconsistency reported. This is purely a frontend derivation bug in Expensify/App; the backend is not involved.

    Suggested fix direction (for the assignees): keep taking the rate value from splitSelectedRate, but derive unit from the transaction's stored distanceUnit (as getRate/mileageRate already does) so the merchant matches the Distance field — matching the issue's Expected Result. Alternatively, if adopting the new unit is intended, also update customUnit.distanceUnit and convert quantity so both surfaces agree; the current half-updated state is the bug.

  9. 4 remaining items

  10. self-assigned this
    on Aug 18, 2026
  11. melvin-bot commented on Aug 19, 2026

    @melvin-bot

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

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

  12. melvin-bot commented on Aug 19, 2026

    @melvin-bot

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

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

  13. 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
  14. melvin-bot commented on Aug 20, 2026

    @melvin-bot

    @ZhenjaHorbach / @dmkt9

    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]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

BugSomething is broken. Auto assigns a BugZero manager.DailyKSv2Engineering

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions