[$250] Expense - Submit button appears briefly after the SmartScan fails

[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: v9.3.26-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #69218
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 15.4.1 Safari/Chrome, iPhone 13 iOS 26.2.1
App Component: Chat Report View

Action Performed:

Precondition: The workspace enables the workflow and setting the default approver

1.Go to https://staging.new.expensify.com
2.Go to the workspace chat
3.Submit an invalid scan receipt
4.Wait until the SmartScan fails

Expected Result:

Submit button should not appear briefly when the SmartScan fails

Actual Result:

Submit button appears briefly after the SmartScan fails

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: @ryntgh

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022027006052413218065
• Upwork Job ID: 2027006052413218065
• Last Price Increase: 2026-02-26

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

[ryntgh]

🚨 Edited by proposal-police: This proposal was edited at 2026-02-26 13:26:58 UTC.

Proposal

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

Expense – Submit button briefly appears after SmartScan fails

What is the root cause of that problem?

There’s a timing gap between when the receipt is marked as SCAN_FAILED and when the SMARTSCAN_FAILED violation is added via Onyx. canSubmit only relies on hasSubmissionBlockingViolations (violations data). During that window, scanning is done (isScanning is false) but the violation is not yet present, so Submit is shown briefly.

App/src/libs/ReportPreviewActionUtils.ts

Lines 48 to 52 in a152afa

	const isAnyReceiptBeingScanned = transactions?.some((transaction) => isScanning(transaction));
	if (transactions?.some((transaction) => hasSubmissionBlockingViolations(transaction, violations, currentUserEmail, currentUserAccountID, report, policy))) {
	return false;
	}

App/src/libs/Violations/ViolationsUtils.ts

Lines 321 to 332 in a152afa

	// Only show SmartScan failed when scan failed AND the user hasn't filled required fields yet
	// Note: amount === 0 is a placeholder value for scanning transactions, not a user-entered value
	const hasUserStartedFixingSmartscan =
	(!TransactionUtils.isAmountMissing(updatedTransaction) && updatedTransaction.amount !== 0) || !TransactionUtils.isMerchantMissing(updatedTransaction);
	const shouldShowSmartScanFailedError =
	isScanRequest &&
	updatedTransaction.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_FAILED &&
	TransactionUtils.hasMissingSmartscanFields(updatedTransaction, iouReport) &&
	!hasUserStartedFixingSmartscan;
	const hasSmartScanFailedError = transactionViolations.some((violation) => violation.name === CONST.VIOLATIONS.SMARTSCAN_FAILED);
	if (shouldShowSmartScanFailedError && !hasSmartScanFailedError) {
	newTransactionViolations.push({name: CONST.VIOLATIONS.SMARTSCAN_FAILED, type: CONST.VIOLATION_TYPES.WARNING, showInReview: true});

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

In canSubmit, add a synchronous check for transactions with receipt.state === SCAN_FAILED and hasMissingSmartscanFields so the Submit button is hidden as soon as SmartScan fails, without waiting for violation data.

Add the new check before the existing hasSubmissionBlockingViolations check:

    const hasSmartScanFailedWithMissingFields = transactions?.some(
        (transaction) =>
            isScanRequest(transaction) &&
            transaction?.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_FAILED &&
            hasMissingSmartscanFields(transaction, report),
    );
    if (hasSmartScanFailedWithMissingFields) {
        return false;
    }

    if (transactions?.some((transaction) => hasSubmissionBlockingViolations(transaction, violations, currentUserEmail, currentUserAccountID, report, policy))) {

App/src/libs/ReportPreviewActionUtils.ts

Lines 49 to 50 in a152afa

	if (transactions?.some((transaction) => hasSubmissionBlockingViolations(transaction, violations, currentUserEmail, currentUserAccountID, report, policy))) {

Do the same for isSubmitAction in ReportPrimaryActionUtils and ReportSecondaryActionUtils

    const hasSmartScanFailedWithMissingFields = reportTransactions?.some(
        (transaction) =>
            isScanRequest(transaction) &&
            transaction?.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_FAILED &&
            hasMissingSmartscanFields(transaction, report),
    );
    if (hasSmartScanFailedWithMissingFields) {
        return false;
    }

App/src/libs/ReportPrimaryActionUtils.ts

Line 123 in a152afa

App/src/libs/ReportSecondaryActionUtils.ts

Line 213 in a152afa

And lastly, in canSubmitReport as well

    const hasSmartScanFailedWithMissingFields = transactions.some(
        (transaction) =>
            isScanRequestTransactionUtils(transaction) &&
            transaction?.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_FAILED &&
            hasMissingSmartscanFields(transaction, report),
    );

App/src/libs/actions/IOU/index.ts

Line 10511 in a152afa

    return (
        ...
        !hasSmartScanFailedWithMissingFields &&
    );

App/src/libs/actions/IOU/index.ts

Lines 10512 to 10521 in a152afa

	return (
	isOpenExpenseReport &&
	(report?.ownerAccountID === currentUserAccountID || report?.managerID === currentUserAccountID || isAdmin) &&
	!hasOnlyPendingCardOrScanFailTransactions &&
	!hasAllPendingRTERViolations &&
	hasTransactionWithoutRTERViolation &&
	!isReportArchived &&
	!hasAnySubmissionBlockingViolations &&
	transactions.length > 0
	);

What alternative solutions did you explore? (Optional)

NA

[MelvinBot]

Proposal

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

When a user submits an invalid scan receipt in a workspace chat (with workflow enabled and a default approver), the Submit button briefly flashes after SmartScan fails. The button should not appear at all when the scan has failed.

What is the root cause of that problem?

This is a race condition between two separate Onyx state updates when SmartScan fails.

The Submit button visibility is controlled by isSubmitAction() in ReportPrimaryActionUtils.ts:91-137. It has two guards that should prevent the button from showing after scan failure:

1. Guard 1 (line 118-122): isScanning() — checks if receipt.state is SCAN_READY or SCANNING. When scan fails, the state changes to SCANFAILED, so this guard immediately drops.

2. Guard 2 (line 124-128): hasSubmissionBlockingViolations() — checks for a SMARTSCAN_FAILED violation in the transaction violations Onyx collection. This violation arrives as a separate Onyx key update from the transaction itself.

3. Guard 3 (line 112, 136): transactionAreComplete — checks transaction.amount !== 0 || transaction.modifiedAmount !== 0. When scan fails with amount === 0 and modifiedAmount === undefined, this evaluates to 0 !== 0 || undefined !== 0 → false || true → true. So this guard incorrectly passes due to JavaScript's loose comparison of undefined !== 0.

When SmartScan fails, the backend sends Onyx updates that change both the transaction (receipt.state → SCANFAILED) and the transaction violations (SMARTSCAN_FAILED violation added). These are stored under separate Onyx collection keys (ONYXKEYS.COLLECTION.TRANSACTION vs ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS). Between the first update being processed (transaction) and the second update being rendered (violations), there is a brief window where:

• Guard 1 is off (isScanning() = false because receipt is no longer SCANNING)
• Guard 2 is off (hasSubmissionBlockingViolations() = false because the violation hasn't been applied yet)
• Guard 3 passes (undefined !== 0 is true)

Result: isSubmitAction() returns true for one render frame, causing the Submit button to flash.

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

Two changes in src/libs/ReportPrimaryActionUtils.ts:

1. Add a direct SCAN_FAILED receipt state check in isSubmitAction() (after the isScanning check at line 122). This covers the timing gap before violations arrive:

Check if any receipt has scan failed with missing smartscan fields.
If so, return false (block submit).

This mirrors the same logic used in ViolationsUtils.ts:321-329 to determine when to add the SMARTSCAN_FAILED violation, ensuring the Submit button is blocked as soon as the receipt state changes — even before the violation data arrives in Onyx. When the user later fixes the fields (amount/merchant), hasMissingSmartscanFields returns false and submit is unblocked, consistent with the existing violation-based flow.

2. Fix the transactionAreComplete check at line 112 to properly handle undefined modifiedAmount. The current check transaction.modifiedAmount !== 0 incorrectly passes when modifiedAmount is undefined. It should additionally verify that modifiedAmount is defined and valid (using the existing hasValidModifiedAmount() utility from TransactionUtils).

What alternative solutions did you explore? (Optional)

• Broadening isScanning() to include SCAN_FAILED — Rejected because isScanning has a clear semantic (the receipt is actively being scanned), and SCAN_FAILED is a terminal state, not a scanning state. Overloading this function would be confusing.
• Ensuring atomic Onyx updates — Even if both updates are in the same Pusher batch, React can still render intermediate states between separate Onyx key updates. This would require changes to Onyx's batch processing, which is a much larger scope.
• Only fixing transactionAreComplete — This would help for the specific case where amount === 0 and modifiedAmount === undefined, but wouldn't protect against cases where the backend sets a non-zero amount during scan failure. The receipt state check is more robust.

---

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 - @ZhenjaHorbach (External)

[melvin-bot]

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

[paulnjs]

Proposal

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

Submit button appears briefly after the SmartScan fails

What is the root cause of that problem?

There's a race condition when SmartScan fails. The Submit button visibility is controlled by multiple checks, and they update at different times:

1. During scanning: isScanning() / isReceiptBeingScanned() returns true because receipt state is SCANNING or SCAN_READY. This blocks the Submit button.
   

   App/src/libs/ReportPrimaryActionUtils.ts

   Line 112 in 324a739

   const transactionAreComplete = reportTransactions.every((transaction) => transaction.amount !== 0 || transaction.modifiedAmount !== 0);

   
   

   App/src/libs/ReportPrimaryActionUtils.ts

   Lines 118 to 121 in 324a739

   	const isAnyReceiptBeingScanned = reportTransactions?.some((transaction) => isScanning(transaction));
   	if (isAnyReceiptBeingScanned) {
   	return false;

2. When SmartScan fails: Receipt state changes to SCAN_FAILED. At this moment:

• isScanning() / isReceiptBeingScanned() immediately returns false (no longer scanning)
• The transactionAreComplete evaluates to true because modifiedAmount is undefined, and undefined !== 0 is true in JavaScript.
• The SMARTSCAN_FAILED violation has not been computed yet (it's computed asynchronously via ViolationsUtils.getViolationsOnyxData), so hasSubmissionBlockingViolations() returns false make the Submit button briefly appears

3. The SMARTSCAN_FAILED violation is computed and stored → hasSubmissionBlockingViolations() returns true → Submit button disappears

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

Added a new hasFailedSmartScan() helper in TransactionUtils that checks if a transaction has a SCAN_FAILED receipt state and is still a partial transaction (user hasn't manually entered the data yet). This check is synchronous and doesn't depend on violations being computed.

function hasFailedSmartScan(transaction: OnyxEntry<Transaction>): boolean {
return transaction?.receipt?.state === CONST.IOU.RECEIPT_STATE.SCAN_FAILED && isPartialTransaction(transaction) && hasReceipt(transaction);
}

Applied this check in the three places that control Submit button visibility:

1. ReportPrimaryActionUtils.ts: isSubmitAction — blocks Submit when any transaction has a failed smart scan
   

   App/src/libs/ReportPrimaryActionUtils.ts

   Line 123 in 324a739

if (reportTransactions?.some((transaction) => hasFailedSmartScan(transaction))) {
return false;
}

2. ReportSecondaryActionUtils.ts same above
3. ReportPreviewActionUtils.ts

const hasAnyFailedSmartScan = transactions?.some((transaction) => hasFailedSmartScan(transaction));
...
return isExpense && (isSubmitter || isManager || isAdmin) && isOpen && !isAnyReceiptBeingScanned && !hasAnyFailedSmartScan && !!transactions && transactions.length > 0;

App/src/libs/ReportPreviewActionUtils.ts

Line 60 in 324a739

return isExpense && (isSubmitter || isManager || isAdmin) && isOpen && !isAnyReceiptBeingScanned && !!transactions && transactions.length > 0;

What alternative solutions did you explore? (Optional)

N/A

[github-actions]

⚠️ @paulnjs Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.