Repository navigation
Scan - "0,00" remains on amount field of split scan on group despite being invalid amount #102960
Description
If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.
Version Number: 9.5.2-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: #98871
Email or phone of affected tester (no customers): ibellicotest+3215@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests
Action Performed:
Prerequisite: Account has a workspace.
- Open the Expensify app.
- Navigate to a group chat (or create one if necessary)
- Split an expense using scan and upload an image that will fail SmartScan.
- Wait until the scan fails.
- Open the split expense details.
- Note that the Amount field is empty instead of showing $0.00.
- Tap on "Amount" field and enter "0" as amount > "Split Expense"
- Note that "Please enter a valid amount before continuing" error message appears.
- Return to chat.
- Note that "Missing Amount" error is still visible and no amount is displayed on preview.
- Reopen expense.
- Note that "Amount" field now shows "0.00" and no error is visible, despite preview still showing "Missing Amount"
Expected Result:
Amount field shouldn´t display "0,00" on failed split scan after being edited, as it is an invalid amount for split expense.
Actual Result:
After editing amount on a failed split scan expense to "0", "Missing Amount" error remains visible on preview but "Amount" field inside report still shows "0,00" despite being an invalid amount for split expense.
Workaround:
Unknown
Platforms:
- Android: App
- Android: mWeb Chrome
- iOS: App
- iOS: mWeb Safari
- iOS: mWeb Chrome
- Windows: Chrome
- MacOS: Chrome Safari
Screenshots/Videos
Bug7277437_1791172179587.0_Scan_1.1.mp4
Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7277437
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
applause-bot commentedon Oct 5, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/433b1da6768ab8ec02ce14656b01089562fbec591dea34fc65b431ab1639382b
melvin-bot commentedon Oct 5, 2026
You have been assigned to this deploy blocker because you recently merged this PR: #98871
melvin-bot commentedon Oct 5, 2026
@arosiclair @Ollyws you have been assigned to this deploy blocker because you reviewed the offending PR: #98871
melvin-bot commentedon Oct 5, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Oct 5, 2026
👋 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:
MelvinBot commentedon Oct 5, 2026
Deploy Blocker Analysis
Causing PR: fix: show scan error instead of populating $0 amount when scan fails (high confidence). It is the only PR in the 9.5.2-0 checklist that touches the split amount field, the amount submit path, and the preview.
Recommendation: demote, then roll forward with a small fix. Do not revert. The reported end state (field shows 0.00, preview shows "Missing amount") already exists on production, from the start. Staging only falls back to it after you enter an invalid 0. Reverting would bring back the original bug on every flow the PR fixed.
Root cause: The PR skips the "amount unchanged" early return for failed-scan placeholders. Entering 0 on a split now writes
modifiedAmount: 0to the split draft. Split Expense correctly blocks 0, but the draft keeps it.isFailedScanAmountPlaceholdertreats 0 as a validmodifiedAmount, so the field shows 0.00. The preview reads the real transaction, so it still shows "Missing amount".Suggested fix: For split edits, don't treat a 0 draft amount as confirmed. Either:
AmountFieldwhenisEditingSplitBill && amount === 0, orsubmitEditAmountand inAmountField.handleAmountChange.Investigation details
All links use the
9.5.2-0commit.amountUtils.ts:14-34: the placeholder check requires!hasValidModifiedAmount(transaction). Lines 6-12 count 0 as valid.IOUAmountSubmission.ts:657-662: the early return is skipped for placeholders. So 0 reachessetDraftSplitTransactionat line 676. On production, entering 0 hit the early return and nothing was written.useConfirmationValidation.ts:340-341: 0 is rejected for split edits ("Please enter a valid amount before continuing"). Nothing reaches the server.AmountField.tsx:127-130: the draft is no longer a placeholder, so the field shows 0.00 with no error.DynamicSplitBillDetailsPage.tsx:199renders that draft.TransactionPreviewUtils.ts:320and lines 253-262: the preview uses the saved transaction, which is still a placeholder, so it shows "Missing amount".Impact: display mismatch in an unsaved split draft only. A 0 split is still blocked, and nothing bad is written to the server.
The PR's test plan (Flow 2) checks a failed split scan before editing, but never tests entering 0.
Next Steps:
x-dev90, please roll forward with the fix above. Reply with@MelvinBot <your feedback>to refine this analysis.view run
x-dev90 commentedon Oct 5, 2026
I reproduced the same behavior in production: after entering
0and reopening the expense, the Amount field shows0.00while the preview still shows “Missing amount.” Since this is reproducible in production, it doesn’t appear to be a regression from PR #98871.Screen.Recording.2026-10-05.at.12.11.04.PM_compressed.mp4
I’m happy to fix it and open a PR if you’d like to assign it to me. Thanks!
arosiclair commentedon Oct 5, 2026
Yup not a regression and I think this behavior is fine. Closing this out