Distance - "changed the expense" message is shown after saving 0 mile distance

[jponikarchuk]

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.2.96-1
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: #77238
Email or phone of affected tester (no customers): applausetester+sjdiosn2djois2j2d@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chroome
App Component: Money Requests

Action Performed:

Precondition:

• Log in with Expensifail account.

1.Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click + > Track distance > Manual.
4. Enter 0 > Next.
5. Click Create expense.
6. Open the expense thread.
7. Click Distance.
8. Enter 0 and save.
9. Right click on "changed the expense" system message > Reply in thread.

Expected Result:

When user saves 0 distance again, system message should show that the distance is set to 0.

Actual Result:

When user saves 0 distance again, system message mentions "changed the expense", which causes error in thread.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @NicMendonca (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[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: #77238 - "Allow zero-amount expenses - ROUND 4" by @Gonals (High confidence)
Related Issues: None found

Recommendation: REVERT

The PR introduced changes to allow zero-amount expenses, but created a regression in the distance request modification message logic. When a user edits a 0-distance expense and saves it as 0 again (even with no actual change), the system displays a generic "changed the expense" message instead of the expected distance-specific message. This also causes an error when trying to reply to that message in a thread.

📋 Detailed Analysis

Evidence

PR #77238 modified ModifiedExpenseMessage.ts and DistanceRequestUtils.ts to properly handle zero-amount expenses. Specifically:

1. In ModifiedExpenseMessage.ts (lines 248-249):

   • Before: const oldAmount = oldAmountValue ? convertToDisplayString(reportActionOriginalMessage?.oldAmount ?? 0, oldCurrency) : '';
   • After: const oldAmount = convertToDisplayString(oldAmountValue, oldCurrency);
   • This change ensures zero amounts are displayed as "$0.00" instead of empty string

2. In DistanceRequestUtils.ts (line 177):

   • Before: if (!hasRoute || !unit || !distanceInMeters)
   • After: if (!hasRoute || !unit)
   • Removed the !distanceInMeters check to allow zero-distance expenses

Root Cause

When a user edits a 0-distance expense and saves it as 0 again:

1. The system creates a MODIFIED_EXPENSE action even though nothing actually changed
2. The merchant string is formatted as "0.00 mi @ $0.00 / mi" for both old and new values
3. The condition at line 256 of ModifiedExpenseMessage.ts checks: hasModifiedAmount && hasModifiedMerchant && merchant.includes('@')
4. However, when the distance hasn't actually changed, the backend may not include the amount in modified fields (only merchant), causing hasModifiedAmount to be false
5. This prevents the distance-specific message handler (getForDistanceRequest) from executing
6. The merchant change is processed generically at lines 304-317, but because both values are identical, the resulting message generation may fail
7. When no proper message fragments are generated, the code falls back to the generic "changed the expense" message (line 487)

This generic message lacks the proper context needed for thread replies, causing the error mentioned in the issue.

Reproducibility

• Issue is staging-only (new feature doesn't exist in production)
• Reproducible on Mac/Chrome as reported
• Affects distance tracking feature specifically