[Due for payment 2026-07-21] If large number is entered in "Exclude a fixed distance per claim", weird error

[applause-bot]

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.4.17-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92496
Email or phone of affected tester (no customers): applausetester+en@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Macbook Pro 2023 / Tahoe 26.4.1
App Component: Workspace Settings

Action Performed:

1. Access staging.new.expensify.com and sign into beta user
2. Go to WS > Distance Rates > Setting > Exclude Commutes choose "Exclude a fixed distance per claim" and set a distance.
3. Input a large number and then click save button

Expected Result:

User expects the number to be entered correctly or if theres a max number, the error message should let the user know.

Actual Result:

User sees an "Oops something went wrong error" that does not specify the reason. This error message is also very close to the bottom button

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188134_1782175859397.Random_error_message.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7188134

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/1eef0e4590410681a4ae8c2e3ded9f1c1392c10eb1e3bae9ff3413c2f1373226

[melvin-bot]

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

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

[MelvinBot]

Proposal

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

On Workspace → Distance Rates → Settings → Exclude Commutes → "Exclude a fixed distance per claim", entering a very large distance shows a generic "Oops, something went wrong" error instead of either accepting the value or telling the user what's wrong.

What is the root cause of that problem?

The form's client-side validation only rejects empty/zero/negative values — it has no upper bound. A large number passes validation and is sent to the backend, which rejects it; the optimistic-update failure path then surfaces the generic error message.

Evidence

• Client validation only checks numeric <= 0, with no max — PolicyCommuterExclusionsPage.tsx:91-97:

  if (!trimmed || Number.isNaN(numeric) || numeric <= 0) {
      setInlineError(translate('workspace.distanceRates.commuterExclusions.errors.distanceMustBePositive'));
      return;
  }

• The value is then sent straight to the API via setPolicyCommuterExclusions (line 104).
• On backend rejection, the failureData sets the generic message — DistanceRate.ts:573-576:

  errorFields: {commuterExclusions: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage')},

  This renders in the OfflineWithFeedback block right above the Save button (lines 166-190) — matching the reporter's note that the error sits very close to the bottom button.
• The only defined error string for this form is distanceMustBePositive — en.ts:6917-6919; there is no "too large" message.

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

Add an explicit upper-bound check to onSave in PolicyCommuterExclusionsPage.tsx, mirroring the existing positive-number check, and show a clear inline error when the value exceeds the maximum:

1. Add a max-distance constant (e.g. CONST.POLICY.COMMUTER_EXCLUSION_MAX_DISTANCE). The exact value should match the backend's accepted limit — please confirm with the feature owner / backend (SetPolicyCommuterExclusions) so client and server agree.
2. In onSave, after the positive check, add: if numeric > MAX, call setInlineError(...) with a new localized message and return before calling setPolicyCommuterExclusions.
3. Add the new error key (e.g. errors.distanceTooLarge, parameterized with the max) to commuterExclusions.errors across all src/languages/*.ts files.

This keeps invalid input from ever reaching the backend and gives the user an actionable message instead of the generic error. Since this is a new, beta-gated feature introduced by #92496, reverting that PR is also a valid deploy-blocker option if a fast fix isn't preferred.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.