[$250] "Amount over MYR 100,000,000.00/person limit" appears and disappears after splitting expense

[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.11-23
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #80163
Email or phone of affected tester (no customers): osidjodsinjosjosjd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.1 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Rules are enabled.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a manual expense with amount 8888888888.88.
4. Open the report.
5. Click More > Split > Save.

Expected Result:

"Amount over MYR 100,000,000.00/person limit" will not appear on the expense row.

Actual Result:

"Amount over MYR 100,000,000.00/person limit" appears briefly and disappears on the expense row.

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022018784079024947766
• Upwork Job ID: 2018784079024947766
• Last Price Increase: 2026-02-10

Issue Owner

Current Issue Owner: @jjcoffee

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (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: #80163 - "feat: increase max allowed number of digits for manual expenses" by @samranahm (High confidence)
Related Issues: #78643

Recommendation: REVERT

PR #80163 should be reverted to prevent users from entering amounts that can trigger policy violation errors during split expense operations.

Labels: No label changes needed - DeployBlockerCash is correctly applied (frontend bug requiring App repo fix)

Detailed Analysis

Evidence

PR #80163 increased CONST.IOU.AMOUNT_MAX_LENGTH from 8 to 10 digits to support larger amounts in certain currencies (e.g., VND). This change allows users to enter amounts like 8,888,888,888.88 MYR (10 digits before decimal).

The changes in PR #80163:

• Modified src/CONST/index.ts: Changed AMOUNT_MAX_LENGTH: 8 to AMOUNT_MAX_LENGTH: 10
• Updated validation regex in AmountWithoutCurrencyInput.tsx to use the new limit
• Updated validation in PolicyDistanceRatesUtils.ts, SearchAutocompleteUtils.ts, and BankAccountValidationForm.tsx

Verification

The PR modifies the following key files that control amount input validation:

• /home/runner/work/App/App/src/CONST/index.ts (AMOUNT_MAX_LENGTH constant)
• /home/runner/work/App/App/src/components/AmountWithoutCurrencyInput.tsx (input validation)
• /home/runner/work/App/App/src/libs/MoneyRequestUtils.ts (amount validation logic - uses AMOUNT_MAX_LENGTH)

Confirmed that PR #80163:

1. Modifies these exact files related to amount validation
2. Changes align with the reported issue timing (merged 2026-02-03T01:32:08Z to staging version 9.3.11-23)
3. The bug only reproduces on staging (where this PR is deployed), not production (where it is not)

Root Cause

PR #80163 inadvertently created a UX issue where the increased digit limit (8 → 10) allows amounts that can exceed policy limits in certain currencies.

Technical flow:

1. User creates manual expense with amount 8,888,888,888.88 MYR (10 digits - now allowed by input validation)
2. User clicks "Split" → "Save" on the expense
3. ViolationsUtils.getViolationsOnyxData() is called to calculate policy violations
4. The function detects overLimit violation because 8,888,888,888.88 > 100,000,000 (MYR policy limit)
5. Violation message "Amount over MYR 100,000,000.00/person limit" appears briefly
6. Violation disappears due to subsequent state updates/recalculations in the split expense flow

The transient error creates user confusion and indicates a validation state mismatch between input validation (allowing 10 digits) and policy rule validation (enforcing currency-specific limits).