[Odometer] Fix trackExpense to persist odometer readings for selfDM tracked expenses

[Julesssss]

Part of the Migrate Odometer project.

trackExpense doesn't send odometerStart/odometerEnd to the API, so tracked expenses (selfDM) lose odometer data after logout/login and are reclassified as manual distance expenses.

Include odometerStart and odometerEnd in the trackExpense request payload to persist odometer readings for tracked expenses.

Issue Owner

Current Issue Owner: @DylanDylann

[melvin-bot]

Triggered auto assignment to @twisterdotcom (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.

[Julesssss]

@MelvinBot investigate this

[MelvinBot]

🔍 Issue Analysis

Summary: The trackExpense function correctly receives odometerStart/odometerEnd from the UI but never includes them in the API request payload, so the server never persists them. After logout/login, the data is lost and the expense is reclassified as a manual distance expense.

Root Cause: The TrackExpenseParams type is missing odometerStart and odometerEnd fields, and the code that builds the API parameters in the trackExpense function's default (CREATE) case omits them entirely. In contrast, createDistanceRequest (for non-TRACK flows) correctly includes both fields.

Recommended Fix:

1. Add odometerStart?: number and odometerEnd?: number to the TrackExpenseParams type in src/libs/API/parameters/TrackExpenseParams.ts
2. Add odometerStart and odometerEnd to the parameters object in the trackExpense default case in src/libs/actions/IOU/index.ts (around line 7196)
3. Investigate whether the isDistance flag at line 7197 should also include isOdometerDistanceRequest (see secondary issue below)

Open Questions

• Does the backend TrackExpense handler already support odometerStart/odometerEnd parameters, or does it also need to be updated?
• Should the ShareTrackedExpenseParams and TrackedExpenseTransactionParams types (used for the CATEGORIZE/SHARE sub-flows) also be updated with odometer fields?
• The isDistance flag in the trackExpense default case does not include isOdometerDistanceRequest — is this an additional bug?

Detailed Investigation

Root Cause Analysis

The odometer data flows correctly through most of the pipeline:

1. UI input: IOURequestStepDistanceOdometer saves readings via setMoneyRequestOdometerReading() into transaction.comment.odometerStart/odometerEnd (src/libs/actions/IOU/index.ts:1699-1706)
2. Confirmation step: IOURequestStepConfirmation reads them from the transaction and passes to trackExpense (src/pages/iou/request/step/IOURequestStepConfirmation.tsx:795-796)
3. trackExpense receives them: Destructured at src/libs/actions/IOU/index.ts:6912-6913
4. Optimistic data is correct: Passed to getTrackExpenseInformation at lines 7003-7004, which builds the optimistic transaction correctly

The bug is at step 5: When building the TrackExpenseParams object for the API call (lines 7161-7198), odometerStart and odometerEnd are simply not included. The TrackExpenseParams type (src/libs/API/parameters/TrackExpenseParams.ts:6-41) doesn't define these fields, so TypeScript doesn't flag the omission.

Evidence Chain

• Working path (createDistanceRequest): CreateDistanceRequestParams (src/libs/API/parameters/CreateDistanceRequestParams.ts:30-31) defines odometerStart?: number and odometerEnd?: number. The createDistanceRequest function includes them at lines 8041-8042 (non-split) and 7944-7945 (split).
• Broken path (trackExpense): TrackExpenseParams lacks these fields entirely. The parameters object at lines 7161-7198 never assigns them. API.write(WRITE_COMMANDS.TRACK_EXPENSE, parameters, onyxData) at line 7203 sends the request without odometer data.
• Why data disappears on logout/login: The optimistic local Onyx data has odometer values (from step 4), so the UI looks correct during the session. But the server never received them, so after logout/login (which fetches fresh data from the server), the odometer fields are empty and the expense falls back to manual distance classification.

Secondary Issue: isDistance Flag

At line 7197, the isDistance flag is computed as:

isGPSDistanceRequest || isMapDistanceRequest(transaction) || isManualDistanceRequestTransactionUtils(transaction)

This does not include isOdometerDistanceRequestTransactionUtils(transaction), which means odometer distance requests may not be flagged as distance requests to the backend.

Relevant Code

• src/libs/API/parameters/TrackExpenseParams.ts:6-41 — Missing odometerStart/odometerEnd fields
• src/libs/API/parameters/CreateDistanceRequestParams.ts:30-31 — Has odometerStart/odometerEnd (working reference)
• src/libs/actions/IOU/index.ts:6912-6913 — trackExpense destructures odometer data
• src/libs/actions/IOU/index.ts:7003-7004 — Passed to optimistic data (correct)
• src/libs/actions/IOU/index.ts:7161-7198 — API params construction (bug: odometer fields missing)
• src/libs/actions/IOU/index.ts:7197 — isDistance flag excludes odometer requests
• src/libs/actions/IOU/index.ts:7203 — API.write call sends params without odometer data
• src/libs/actions/IOU/index.ts:8041-8042 — createDistanceRequest includes odometer (working reference)

Implementation Notes

• The fix mirrors the existing pattern in createDistanceRequest — add the two fields to the type and include them in the params object
• Consider also updating TrackedExpenseTransactionParams (line 380-388) and ShareTrackedExpenseParams for the CATEGORIZE/SHARE sub-flows if those paths can also handle odometer expenses
• Verify backend support for these params on the TrackExpense command before deploying the client-side fix

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[Julesssss]

@MelvinBot implement this

[MelvinBot]

🤖 Draft PR created: #81770

Changes:

1. Added odometerStart and odometerEnd to the TrackExpenseParams type
2. Included both fields in the trackExpense API parameters (default/CREATE case)
3. Added isOdometerDistanceRequest to the isDistance flag computation

Note: The CategorizeTrackedExpenseParams and ShareTrackedExpenseParams types (used for CATEGORIZE/SHARE sub-flows) also lack odometer fields. If those paths can handle odometer expenses, they may need a similar update in a follow-up.

Note: Full TypeScript compilation could not be verified in CI due to environment memory constraints (OOM). The changes are minimal type additions and property assignments following the existing CreateDistanceRequestParams / createDistanceRequest pattern.

Please mark it as "Ready for review" when it is ready for review.