[Due for payment 2026-03-23] [$250] Report-Error and infinite loading when submitting track expense to WS with workflows disabled

[nlemma]

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.2.86-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-2487/folder/13176877/41237352/1089918656
Email or phone of affected tester (no customers): ibellicotest+2230@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Critical User Impact
Device used: Motorola MotoG60 / Android 12 / Chrome ( mWeb / Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has Self DM.
Prerequisite 2: Account has a workspace with workflows disabled.

1. Open the staging.new.expensify.com website.
2. Create a manual expense and submit it to Self DM.
3. Tap on "Submit it to someone" option on whisper message.
4. Select a workspace and submit the expense to it.
5. Open the expense report.
6. Note that "Unexpected error submitting this expense" and "Unexpected error deleting this expenses" error messages appear on report.
7. Dismiss the errors.
8. Note that you are redirected back to chat, and report is now displayed empty.
9. Reopen report.
10. Note that infinite skeleton loader is displayed.
11. Tap on "More"
12. Note that there is no option to delete the empty report.
13. Tap on "Retract"
14. Note that no action is triggered.

Expected Result:

User should be able to submit a track expense to a workspace, even if workflows are disabled.

Actual Result:

"Unexpected error submitting this expenses" and "Unexpected error deleting this expenses" error messages appear at the same time when submitting a track expense to a workspace with workflows disabled. Also, when errors are dismissed, report displays infinite skeleton loader and it can´t be deleted or retracted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7035755_1766466245358.Flow.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022003566431205148800
• Upwork Job ID: 2003566431205148800
• Last Price Increase: 2025-12-30

Issue Owner

Current Issue Owner: @cead22

[melvin-bot]

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

[annaweber830]

Proposal

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

User should be able to submit a track expense to a workspace, even if workflows are disabled.

What is the root cause of that problem?

When submitting a track expense to a workspace with workflows disabled:

1. shareTrackedExpense requires accountantEmail and accountantAccountID from accountantParams.
2. If these are missing, the function returns early without making the API call.
   

   App/src/libs/actions/IOU.ts

   Lines 6187 to 6189 in 76cac98

   	if (!policyID || !chatReportID || !accountantEmail || !accountantAccountID) {
   	return;
   	}

3. However, getConvertTrackedExpenseInformation is called before the check , which sets up optimistic data including failure data for deleting the transaction from the track expense report.

   App/src/libs/actions/IOU.ts

   Lines 6206 to 6215 in 76cac98

   	const {optimisticData, successData, failureData, modifiedExpenseReportActionID} = getConvertTrackedExpenseInformation(
   	transactionID,
   	actionableWhisperReportActionID,
   	moneyRequestReportID,
   	linkedTrackedExpenseReportAction,
   	linkedTrackedExpenseReportID,
   	transactionThreadReportID,
   	CONST.IOU.ACTION.SHARE,
   	isLinkedTrackedExpenseReportArchived,
   	);

4. Since the API call never happens, the optimistic data remains, causing both:
   "Unexpected error submitting this expense" (from the failed submit)
   "Unexpected error deleting this expense" (from the optimistic delete operation)
   This leaves the report in an infinite loading state because the optimistic updates were applied but the API call never completed

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

Modified shareTrackedExpense to derive the accountant from the workspace when accountantParams is missing:

1. If accountantParams is missing but a policy exists, use the workspace owner as the accountant.
2. If no owner is available, fall back to the first admin in the workspace.
3. This ensures the API call proceeds even when accountantParams isn't provided, allowing track expenses to be submitted to workspaces with workflows disabled.

let accountantEmail = addSMSDomainIfPhoneNumber(accountantParams?.accountant?.login);
    let accountantAccountID = accountantParams?.accountant?.accountID;
    if ((!accountantEmail || !accountantAccountID) && policyParams?.policy) {
        const policy = policyParams.policy;
        if (policy.owner && policy.ownerAccountID) {
            accountantEmail = addSMSDomainIfPhoneNumber(policy.owner);
            accountantAccountID = policy.ownerAccountID;
        } else {
            const policyEmployeeList = policy.employeeList;
            if (policyEmployeeList) {
                for (const [email, employee] of Object.entries(policyEmployeeList)) {
                    if (employee.role === CONST.POLICY.ROLE.ADMIN && !isDeletedPolicyEmployee(employee, false)) {
                        accountantEmail = addSMSDomainIfPhoneNumber(email);
                        accountantAccountID = getMemberAccountIDsForWorkspace(policyEmployeeList, false, false)[email];
                        break;
                    }
                }
            }
        }
    }

What alternative solutions did you explore? (Optional)

[melvin-bot]

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

[melvin-bot]

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

[CortneyOfstad]

Hey @suneox! There is a proposal above for you to review. Thanks!

[lorretheboy]

Proposal

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

Error and infinite loading when submitting track expense to WS with workflows disabled

What is the root cause of that problem?

shouldCreateNewMoneyRequestReport function receives the action parameter but doesn't use it to determine if this is a moving transaction

App/src/libs/ReportUtils.ts

Lines 11104 to 11121 in 097438c

	function shouldCreateNewMoneyRequestReport(
	existingIOUReport: OnyxInputOrEntry<Report> | undefined,
	chatReport: OnyxInputOrEntry<Report>,
	isScanRequest: boolean,
	action?: IOUAction,
	): boolean {
	if (existingIOUReport && !!existingIOUReport.errorFields?.createChat) {
	return true;
	}
	const isASAPSubmitBetaEnabled = Permissions.isBetaEnabled(CONST.BETAS.ASAP_SUBMIT, allBetas);
	return (
	!existingIOUReport ||
	hasIOUWaitingOnCurrentUserBankAccount(chatReport) ||
	!canAddTransaction(existingIOUReport) ||
	(action !== CONST.IOU.ACTION.SUBMIT && isScanRequest && isASAPSubmitBetaEnabled)
	);
	}

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

We should update to handle moving transaction as well

function shouldCreateNewMoneyRequestReport(
    existingIOUReport: OnyxInputOrEntry<Report> | undefined,
    chatReport: OnyxInputOrEntry<Report>,
    isScanRequest: boolean,
    action?: IOUAction,
): boolean {
    if (existingIOUReport && !!existingIOUReport.errorFields?.createChat) {
        return true;
    }

    const isASAPSubmitBetaEnabled = Permissions.isBetaEnabled(CONST.BETAS.ASAP_SUBMIT, allBetas);
    const isMovingTransaction = action === CONST.IOU.ACTION.SUBMIT || action === CONST.IOU.ACTION.SHARE || action === CONST.IOU.ACTION.CATEGORIZE;
    return (
        !existingIOUReport ||
        hasIOUWaitingOnCurrentUserBankAccount(chatReport) ||
        !canAddTransaction(existingIOUReport, false, isMovingTransaction) ||
        (action !== CONST.IOU.ACTION.SUBMIT && isScanRequest && isASAPSubmitBetaEnabled)
    );
}

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[suneox]

Thank for all proposals I'll take a look at this one soon