[Due for payment 2026-03-30] Split - "Please enter a valid amount before continuing" persists after removing split

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

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Open the expense.
5. Click More > Split.
6. Click Add split.
7. Edit the added split from Step 6 to 0.00.
8. Click Save.
9. Click the split with 0.00 amount.
10. Click Remove split

Expected Result:

"Please enter a valid amount before continuing" will disappear after removing the split.

Actual Result:

"Please enter a valid amount before continuing" persists after removing the split.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7105356_1773757142381.3.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #81905 - "Add support to splits for negative values" by @kubabutkiewicz (High confidence)
Related Issues: None identified

Recommendation: REVERT

PR #81905 introduced support for negative amounts in split expenses but created an edge case where validation errors persist incorrectly. The error state management does not account for splits being removed.

Labels: No changes needed - DeployBlockerCash is correctly applied (frontend bug blocks App deploy only)

📋 Detailed Analysis

Evidence

The issue occurs when:

1. User creates a split expense
2. User edits a split amount to 0.00
3. User clicks Save (triggers validation error "Please enter a valid amount before continuing")
4. User clicks the split with 0.00 amount
5. User clicks "Remove split"
6. User returns to the main split page - error message persists even though the problematic split is gone

Root Cause

File: /home/runner/_work/App/App/src/pages/iou/SplitExpensePage.tsx

The error message is stored in local state (line 76). The error is set when saving with a 0.00 amount split (lines 270-273). The error is only cleared when a value changes or when attempting to save again.

The bug: When a split is removed via the "Remove split" button in SplitExpenseEditPage.tsx (line 358), the page navigates back to SplitExpensePage but the errorMessage state persists because the removal happens in a different page and there's no logic to clear the error when the split list changes.

Verification

PR #81905 modified split expense handling to support negative values, touching these key files:

• ✅ src/pages/iou/SplitExpensePage.tsx - Main page where error persists
• ✅ src/components/SelectionList/ListItem/SplitListItem/SplitAmountInput.tsx - Added shouldAllowNegative and keyboardType
• ✅ src/libs/IOUUtils.ts - Updated percentage/amount calculations for negative values
• ✅ src/libs/MoneyRequestUtils.ts - Updated validation functions

The PR merged on 2026-03-17 at 10:27:52Z, and the issue was reported on 2026-03-17 at 14:38:13Z (4 hours later), matching the timeline perfectly.

The issue is reproducible only on staging (not production), confirming it's caused by a PR in the current staging deploy.