Odometer - Unexpected error when submit expense with image

[mitarachim]

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: v9.3.38-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83556
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Xiaomi RedMi Note 10 / Android 12
App Component: Money Requests

Action Performed:

1. Press FAB -> go to "Track distance" -> choose "Odometer" tab
2. Enter start and end odometer readings
3. Press on the photo thumbnail -> capture or pick an image -> verify it is shown in the thumbnail (do that for both Start and End)
4. Press "Next" -> verify no error is shon and navigation proceeds normally
5. Create expense

Expected Result:

Expense created. No unexpected error. Image is added as receipt.

Actual Result:

Expense created. Unexpected error appears. When user dismiss an error ,expense is deleted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7104156_1773664547402.Screenrecorder-2026-03-16-14-05-34-626.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @jakubkalinski0

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #83556 - "[Odometer] Image stitching" by @jakubkalinski0 (High confidence)
Related Issues: #84998 (already tracking the architectural issue)
Fix PR: #85105 - "[Odometer] Move odometer image stitching to confirmation page" (already in review)

Recommendation: ROLL FORWARD

PR #85105 is already open and addresses this exact issue by moving image stitching to the confirmation page, which is the proper architectural fix. Reverting PR #83556 would remove the entire odometer image stitching feature, which is worse than the current bug. The fix PR is ready for review and should be expedited.

Labels: Keeping DeployBlockerCash (App PR caused the issue, not reproducible in production). Removing DeployBlocker (this is a frontend-only bug, no backend changes needed).

📋 Detailed Analysis

Evidence

The bug is reproducible only in staging (v9.3.38-0) and not in production, matching exactly when PR #83556 was merged (2026-03-13). The PR introduces image stitching functionality for odometer distance requests, which directly correlates with the reported issue: "Unexpected error when submit expense with image" in the odometer flow.

The issue description confirms:

• Steps to reproduce involve odometer image capture (both start and end photos)
• Error appears on submission
• Expense is deleted when error is dismissed
• Only affects Android App platform

Verification

PR #83556 modified the following critical files:

• src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx - Main odometer submission flow
• src/libs/stitchOdometerImages/index.native.ts - Native image stitching implementation
• src/libs/stitchOdometerImages/index.ts - Web image stitching implementation

The changes introduce async image processing in the submission flow, which can fail on Android devices.

Root Cause

The bug is in IOURequestStepDistanceOdometer.tsx in the navigateToNextPage() function (lines 373-467):

1. Lines 376-379: Transaction data (odometer readings, distance) is saved to Onyx synchronously
2. Lines 382-388: Image stitching is attempted asynchronously via stitchOdometerImages() - this can fail
3. Lines 390-398: Receipt is set ONLY if stitching succeeds

When image stitching fails (due to memory constraints, Skia errors on Android, corrupt images, or file system issues):

• The catch block at line 384-387 sets an error message and returns early
• However, transaction data was already saved to Onyx in step 1
• This creates a partial/corrupted expense without a receipt
• Downstream validation detects this invalid state and deletes the transaction when the error is dismissed

Why it happens on Android specifically:
The native implementation (index.native.ts) uses @shopify/react-native-skia for GPU-accelerated image compositing, which can fail on certain Android devices with:

• Limited memory (lines 21-44 load and process images in memory)
• Skia initialization issues (lines 23-24, 32-34)
• File system permission issues (lines 48-50, 56-57)

The web implementation uses simpler Canvas API and is less prone to failure.

Why PR #85105 is the proper fix:
The fix PR moves stitching to the confirmation page, which:

1. Allows immediate navigation (better UX)
2. Shows loading state during stitching
3. Handles errors gracefully on the confirmation page where the expense is already created
4. Prevents the race condition that creates partial transactions

This is the architecturally correct solution, as confirmed by the original PR author and design feedback.