[Due for payment 2026-03-30] Odometer - User can input any character in the Odometer input field

[lanitochka17]

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.31-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #78291
Email or phone of affected tester (no customers): applausetester+ds@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 14.5/ Chrome
App Component: Other

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Click on the + button > Track Distance
3. Switch to Odometer
4. Write any character on the field

Expected Result:

User is only able to input numbers, commas, full stops

Actual Result:

User can input any character

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7094089_1772660113080.Screen_Recording_2026-03-05_at_12.28.22_at_night.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @stephanieelliott (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: #83170 - "Add frontend validation for distance expense amounts exceeding backend limit (v2)" by @neildotexpensify (High confidence)
Related Issues: None

Recommendation: ROLL FORWARD

The bug is straightforward to fix - the input handlers need to normalize/clean the text before setting it to state. Rolling forward with a fix is simpler than reverting PR #83170, which added important validation logic to prevent backend errors.

Labels: No label changes needed - this is correctly labeled as DeployBlockerCash (App deploy blocker)

Detailed Analysis

Evidence

PR #83170 refactored the odometer input validation logic, replacing the cleanOdometerReading() function with isOdometerInputValid(). This change introduced a critical bug:

Before (working):

const handleStartReadingChange = (text: string) => {
    const cleaned = cleanOdometerReading(text);  // Strips invalid characters
    setStartReading(cleaned);                     // Sets the cleaned value
}

After (broken):

const handleStartReadingChange = (text: string) => {
    if (!isOdometerInputValid(text, startReading)) {
        return;
    }
    setStartReading(text);  // BUG: Sets raw text, not cleaned!
}

Verification

1. The bug is in /home/runner/_work/App/App/src/pages/iou/request/step/IOURequestStepDistanceOdometer.tsx lines 305-323
2. PR Add frontend validation for distance expense amounts exceeding backend limit (v2) #83170 modified this file on 2026-03-02, changing the input handling logic
3. The isOdometerInputValid function validates the NORMALIZED text (via DistanceRequestUtils.normalizeOdometerText) but doesn't clean the input before it's set to state
4. Result: When a user types "abc123", the validation normalizes it to "123" which passes validation, then sets "abc123" to state, displaying the letters in the input field

Root Cause

The refactoring separated validation from cleaning. isOdometerInputValid only checks if the normalized text is valid, but handleStartReadingChange and handleEndReadingChange set the raw input text instead of the normalized version.

Fix Required

In IOURequestStepDistanceOdometer.tsx, the handlers should normalize the text before setting it:

const handleStartReadingChange = (text: string) => {
    if (!isOdometerInputValid(text, startReading)) {
        return;
    }
    const normalized = DistanceRequestUtils.normalizeOdometerText(text, fromLocaleDigit);
    setStartReading(normalized);  // Set normalized text
    if (formError) {
        setFormError(''<empty>);
    }
};

Same fix needed for handleEndReadingChange.

Why Not PR #78291?

Melvin-bot initially assigned this to PR #78291, but that PR only refactored the DiscardChangesConfirmation component and didn't touch the input validation logic. PR #78291 merged after PR #83170 had already introduced the bug.