[$250] Distance Expense - "Total amount too large" validation not triggered

[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.3.31-2
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #83170
Email or phone of affected tester (no customers): applausetester+ap34@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11
App Component: Other

Action Performed:

1. Open the app.
2. Start creating a new distance expense.
3. Select the Odometer tab.
4. Enter start reading 0.
5. Attempt to enter a very large end reading value (e.g., 999999999).
6. Observe the behavior of the input field.
7. Switch to the Manual distance tab.
8. Enter an extremely large distance value (e.g., 9999999999).
9. Observe the behavior.

Expected Result:

The system displays the error message:
"The total amount is too large. Reduce the distance or lower the rate."
when the entered values generate an amount exceeding the allowed limit.

Actual Result:

Odometer tab:
The input field restricts the value to 7 numeric characters, preventing users from entering values large enough to trigger the validation error described in the PR.
Manual distance tab:
The field allows entering very large values (up to 10 numeric characters), but the expected validation error message does not appear.
This behavior contradicts the validation described in the PR, where the client-side validation should prevent submitting values that exceed the backend amount limit.

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

Issue Owner

Current Issue Owner: @hoangzinh

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022029538405384111310
• Upwork Job ID: 2029538405384111310
• Last Price Increase: 2026-03-05

[melvin-bot]

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

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The "total amount is too large" validation error, added in PR #83170, never triggers for distance expenses:

• Odometer tab: Input is value-capped at ODOMETER_MAX_VALUE (9,999,999.9), so the maximum possible distance (~10M units) multiplied by typical mileage rates (e.g., USD 72.5¢/mi) produces ~$7.25M — far below the $10B backend limit.
• Manual distance tab: Input is character-limited to 10 digits (defaults to AMOUNT_MAX_LENGTH), so the maximum distance (9,999,999,999) at USD 72.5¢/mi produces ~$7.25B — still below the $10B limit. The validation passes when it should fail.

What is the root cause of that problem?

Manual distance tab (IOURequestStepDistanceManual.tsx): The page does not pass a maxLength prop to NumberWithSymbolForm, so it falls back to CONST.IOU.AMOUNT_MAX_LENGTH (10 digits) in validateAmount(). This limits input to 10 digits. A dedicated constant CONST.IOU.DISTANCE_REQUEST_AMOUNT_MAX_LENGTH (14) already exists and is used in MoneyRequestConfirmationList.tsx for the same purpose, but it was never wired into the manual distance input — an oversight from PR #83170.

With only 10 digits and typical rates (USD P2P = 72.5¢/mi), distance × rate cannot exceed MAX_SAFE_AMOUNT (999,999,999,999 cents), so the isDistanceAmountWithinLimit() check always passes.

Odometer tab (IOURequestStepDistanceOdometer.tsx): The per-keystroke validator isOdometerInputValid caps each reading at ODOMETER_MAX_VALUE (9,999,999.9). This is an intentional cap for realistic odometer readings. With a max distance of ~10M units and any rate below ~$1,000/unit, the amount stays well under the backend limit. The "total amount too large" validation exists as a safety net for extreme custom rates, but is unreachable for standard mileage rates.

What changes do you think we should make in order to solve the problem?

Manual distance tab fix: In IOURequestStepDistanceManual.tsx, pass maxLength={CONST.IOU.DISTANCE_REQUEST_AMOUNT_MAX_LENGTH} to the NumberWithSymbolForm component. This allows up to 14 digits of distance input, making isDistanceAmountWithinLimit() reachable even with low rates (e.g., at 72.5¢/mi, a 13-digit distance would produce an amount exceeding the limit and trigger the error).

Odometer tab: No code change needed. The ODOMETER_MAX_VALUE cap is an intentional design decision for realistic odometer readings (~10M max). The amount validation serves as a safety net for extreme custom rates. The backend is already protected because the input cap prevents amounts that would exceed the WAF limit at typical rates.

What alternative solutions did you explore? (Optional)

• Lowering MAX_SAFE_AMOUNT: Would make the validation trigger earlier but would also reject legitimately large expenses, and wouldn't match the actual backend limit.
• Dynamic input length based on rate: Would be more precise but adds complexity. The existing DISTANCE_REQUEST_AMOUNT_MAX_LENGTH constant was clearly designed for this use case and is simpler.
• Raising ODOMETER_MAX_VALUE: Would allow larger odometer readings but 9,999,999.9 already covers commercial vehicles; higher values would be unrealistic and could cause other issues.

---

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

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @hoangzinh (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022029538405384111310

[twilight2294]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The "total amount too large" validation error, added in PR #83170, never triggers for distance expenses. Users can enter extremely large distance values in both the Odometer and Manual distance tabs, but the validation message does not appear even when the calculated amount should exceed the backend's $10B limit.

What is the root cause of that problem?

The validation logic in isDistanceAmountWithinLimit() within DistanceRequestUtils is correct, but input constraints in both tabs prevent users from entering distance values large enough to trigger the error.

In the Odometer tab (IOURequestStepDistanceOdometer), the isOdometerInputValid() function caps each odometer reading at CONST.IOU.ODOMETER_MAX_VALUE (9,999,999.9). With typical mileage rates like USD $0.725/mi (72.5 cents/mi), the maximum possible amount is 9,999,999.9 × 72.5 = 724,999,992.75 cents (~$7.25M), which is far below MAX_SAFE_AMOUNT (999,999,999,999 cents = $10B). To trigger the validation at this rate, a distance of ~13.8 billion units would be needed, but the odometer cap prevents this.

In the Manual distance tab (IOURequestStepDistanceManual), the NumberWithSymbolForm component is rendered without a maxLength prop, causing it to default to CONST.IOU.AMOUNT_MAX_LENGTH (10 digits) in the underlying validation. This allows inputs up to 9,999,999,999 units, which at 72.5 cents/mi produces 724,999,999,927.5 cents (~$7.25B)—still below the $10B threshold. The validation can only trigger with rates higher than ~100 cents/unit, making it effectively unreachable for standard mileage rates.

What changes do you think we should make in order to solve the problem?

For the Manual distance tab, add dynamic input validation that calculates the maximum allowed distance based on the current rate:

In IOURequestStepDistanceManual, calculate and pass a maxLength prop to NumberWithSymbolForm:

const maxAllowedDistance = Math.floor(CONST.IOU.MAX_SAFE_AMOUNT / rate);
const maxLength = maxAllowedDistance.toString().length;

<NumberWithSymbolForm
    ref={textInput}
    numberFormRef={numberFormRef}
    value={distance?.toString()}
    onInputChange={() => { ... }}
    decimals={CONST.DISTANCE_DECIMAL_PLACES}
    maxLength={maxLength}

For the Odometer tab, modify the validation in IOURequestStepDistanceOdometer to check against a rate-based maximum:

const maxAllowedDistance = Math.floor(CONST.IOU.MAX_SAFE_AMOUNT / rate);
const effectiveMaxDistance = Math.min(CONST.IOU.ODOMETER_MAX_VALUE, maxAllowedDistance);

if (!Number.isNaN(value) && value > effectiveMaxDistance) {
    return false;
}

This ensures both tabs respect the backend's $10B limit while maintaining realistic odometer caps.

What alternative solutions did you explore? (Optional)

Option 1: Simply increase or remove the input limits—rejected because it would allow unrealistic odometer readings (billions of miles) and doesn't provide proactive feedback.

Option 2: Add validation only at submission time—rejected because users wouldn't get immediate feedback and could waste time entering invalid data.

Option 3: Use a fixed higher maxLength like CONST.IOU.DISTANCE_REQUEST_AMOUNT_MAX_LENGTH (14)—rejected because it doesn't account for varying mileage rates across currencies and would still allow invalid inputs with high rates.

The proposed solution provides immediate, rate-aware feedback and prevents invalid data entry while maintaining realistic constraints.