[$250] Expense - Unexpected error when employee create expense after admin disable workflow

[nlemma]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: v9.2.43-0 Reproducible in staging?: Yes Reproducible in production?: Yes If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-1739/folder/13176705/41236831/991933390 Email or phone of affected tester (no customers): N/A Issue reported by: Applause Internal Team Device used: Win 11/Chrome App Component: Money Requests

Action Performed:

Precondition: Create a workspace and invite an employee, set Submission frequency: Instantly, disable Add approvals, enable Make or track payments

1. Open https://staging.new.expensify.com
2. Employee go to workspace chat and create a manual expense
3. Owner go to workspace setting, click on More features and disable Workflows
4. Employee go to workspace chat and create a manual expense
5. Employee click on this expense report

Expected Result:

The new expense at step 4 should be created on new report

Actual Result:

The new expense at step 4 is created on the same report with expense at step 2 and error "Unexpected error submitting this expense. Please try again later" is displayed

Workaround:

Unknown

Platforms:

• [x] Android: App
• [x] Android: mWeb Chrome
• [x] iOS: App
• [x] iOS: mWeb Safari
• [x] iOS: mWeb Chrome
• [x] Windows: Chrome
• [x] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

https://github.com/user-attachments/assets/0c7ebe27-3beb-4a96-9a66-eb980e5e7efe

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021986425784666710707
• Upwork Job ID: 1986425784666710707
• Last Price Increase: 2025-12-25

Issue Owner

Current Issue Owner: @thesahindia

[melvin-bot[bot]]

Triggered auto assignment to @bfitzexpensify (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.

[abbasifaizan70]

Proposal

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

When a workspace has instant submit enabled and workflows are disabled after an expense has already been submitted, new expenses created afterward are incorrectly added to the existing processing report instead of creating a new report. This causes a backend error: "Unexpected error submitting this expense. Please try again later."

What is the root cause of that problem?

The canAddOrDeleteTransactions function in ReportUtils.ts checks if instant submit is enabled before allowing transactions to be added to a processing report. However, when workflows are disabled:

1. The policy's autoReporting is set to false, which causes isInstantSubmitEnabled(policy) to return false
2. The current code only checks if (isInstantSubmitEnabled(policy) && isProcessingReport(moneyRequestReport)) and allows transactions if this condition is false
3. This means processing reports can still accept transactions when instant submit is disabled
4. The backend rejects these transactions because processing reports cannot accept new expenses when instant submit is disabled

The issue is that the code doesn't explicitly prevent adding transactions to processing reports when instant submit is disabled.

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

Update the canAddOrDeleteTransactions function to explicitly check if a report is processing and instant submit is disabled, and return false in that case. This will prevent the expense from being added to the existing processing report, causing shouldCreateNewMoneyRequestReport to return true and create a new report instead.

Changes:

• In src/libs/ReportUtils.ts, modify the canAddOrDeleteTransactions function to check processing reports first
• If the report is processing and instant submit is disabled, return false immediately
• This ensures that when instant submit is disabled, new expenses create new reports instead of being appended to existing processing reports

Code Change:

if (isProcessingReport(moneyRequestReport)) {
    if (!isInstantSubmitEnabled(policy)) {
        // Submitted reports can't accept new transactions when instant submit is disabled.
        // Otherwise, the expense would be appended to the existing processing report and fail on the backend.
        return false;
    }
    return isAwaitingFirstLevelApproval(moneyRequestReport);
}

What alternative solutions did you explore? (Optional)

1. Backend Solution: Modify the backend to accept transactions on processing reports even when instant submit is disabled. However, this would change the business logic and may not be the desired behavior.

2. Policy State Check: Check if workflows were recently disabled and handle existing processing reports differently. This adds complexity and would require tracking policy state changes.

3. Report Status Migration: When workflows are disabled, automatically close or change the status of existing processing reports. This could be disruptive to users and may affect other workflows.

The proposed solution is the cleanest approach as it prevents the issue at the source (the transaction validation logic) without requiring backend changes or complex state tracking.

[melvin-bot[bot]]

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

[melvin-bot[bot]]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

@bfitzexpensify @thesahindia this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

This issue has not been updated in over 14 days. @bfitzexpensify, @thesahindia eroding to Weekly issue.

[melvin-bot[bot]]

@bfitzexpensify @thesahindia this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mavrickdeveloper]

imo (early check in shouldCreateNewMoneyRequestReport) is a more appropriate path because it catches the problem at the exact decision point meaning failing fast before any downstream logic runs. Unlike fixing canAddOrDeleteTransactions

Proposal

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

When an employee creates an expense after an admin disables workflows, the employee sees "Unexpected error submitting this expense. Please try again later." The expense appears to be added to an existing PROCESSING report instead of creating a new one, causing the backend to reject the transaction

What is the root cause of that problem?

The root cause is in:

https://github.com/Expensify/App/blob/0d46409cb08cead93fbdc9de525f4af09f3fe788/src/libs/ReportUtils.ts#L11092-L11109

When deciding whether to create a new expense report, this function calls canAddTransaction() which eventually checks

https://github.com/Expensify/App/blob/0d46409cb08cead93fbdc9de525f4af09f3fe788/src/libs/ReportUtils.ts#L1973-L1983

This returns true for PROCESSING reports awaiting approval, regardless of whether instant submit is currently enabled in the policy.

The problem is:

1. When workflows are disabled, autoReporting becomes false
2. isInstantSubmitEnabled returns false
3. But isAwaitingFirstLevelApproval still returns true for the existing PROCESSING report
4. So canAddTransaction returns true → shouldCreateNewMoneyRequestReport returns false
5. The new expense is added to the existing PROCESSING report
6. The backend rejects this because instant submit is disabled → "Unexpected error"

The function doesn't check if instant submit is currently enabled before allowing additions to a PROCESSING expense report.

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

Add an early return check in shouldCreateNewMoneyRequestReport (after the existing errorFields?.createChat check) that forces new report creation when:

• The existing report is in PROCESSING state
• The existing report is an expense report
• Instant submit is NOT currently enabled in the policy

This check should run before canAddTransaction() is evaluated, ensuring we create a new report when the policy state has changed.

At level of:

https://github.com/Expensify/App/blob/0d46409cb08cead93fbdc9de525f4af09f3fe788/src/libs/ReportUtils.ts#L11092-L11109

new check after line 11100 (the errorFields?.createChat block) and before line 11102 (isASAPSubmitBetaEnabled)

The fix uses existing functions already available in the file:

• isProcessingReport (already in ReportUtils)
• isExpenseReport (already in ReportUtils)
• getPolicy (already defined locally in ReportUtils)
• isInstantSubmitEnabled (already imported from PolicyUtils)

What alternative solutions did you explore? (Optional)

--

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[melvin-bot[bot]]

This issue has not been updated in over 15 days. @bfitzexpensify, @thesahindia eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[mvtglobally]

Issue not reproducible during KI retests. (Third week)