[Due for payment 2025-03-05] [$250] Track expense - App is stuck on confirmation page when submitting track expense

[IuliiaHerets]

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.0.68-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
Email or phone of affected tester (no customers): applausetester+kh1211008@applause.expensifail.com
Issue reported by: Applause Internal Team

Action Performed:

Precondition:

• Account has only one workspace.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Track a manual expense.
4. Click Categorize it.
5. Select a category, enter merchant and submit the expense to the workspace.
6. Delete the workspace.
7. Open FAB.
8. Click Track expense under Quick action.
9. Enter amount > Next.
10. Select a user.
11. Click Submit on the confirmation page.
12. Might need to repeat Step 7 to 11 if user can submit the track expense (it will show error in the report if the submit is successful).

Expected Result:

In Step 9. after entering amount, app should proceed to confirmation page to submit the track expense to self DM because we cannot directly submit track expense to other user.

Actual Result:

In Step 9. after entering amount, user can select other recipient to submit the track expense.
As a result, app is stuck on the confirmation page when trying to submit track expense directly to other user.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6679635_1732844020557.20241129_092659.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021863595844310832183
• Upwork Job ID: 1863595844310832183
• Last Price Increase: 2024-12-16
• Automatic offers:
• FitseTLT | Contributor | 105374583

Issue Owner

Current Issue Owner: @isabelastisser

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

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

[FitseTLT]

Edited by proposal-police: This proposal was edited at 2024-12-03 23:15:45 UTC.

Proposal

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

Track expense - App is stuck on confirmation page when submitting track expense

What is the root cause of that problem?

When categorizing (or even sharing) we are setting the quick action to track and the chatReportID to the chat report target we are submitting to here

App/src/libs/actions/IOU.ts

Lines 1381 to 1386 in 6482913

	onyxMethod: Onyx.METHOD.SET,
	key: ONYXKEYS.NVP_QUICK_ACTION_GLOBAL_CREATE,
	value: {
	action: newQuickAction,
	chatReportID: chatReport.reportID,
	isFirstQuickAction: isEmptyObject(quickAction),

this function is used for tracking expense case on that case it has no problem because the chatReport is the selfDM so our quick action will navigate to track flow with report id as the self dm but the problem is we use it for categorizing flow and in that case the chat report is the policyExpense chat so we are setting the quick action to track with quickActionReportID as the workspace chat.

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

We have two options to solve it

1. On categorizing/sharing case we can set the quick action to request type instead of track type so that now the quick action will be request for the expense chat
   

   App/src/libs/actions/IOU.ts

   Lines 1359 to 1364 in 6482913

   	let newQuickAction: ValueOf<typeof CONST.QUICK_ACTIONS> = CONST.QUICK_ACTIONS.TRACK_MANUAL;
   	if (isScanRequest) {
   	newQuickAction = CONST.QUICK_ACTIONS.TRACK_SCAN;
   	} else if (isDistanceRequest) {
   	newQuickAction = CONST.QUICK_ACTIONS.TRACK_DISTANCE;
   	}

 const isSelfDM = ReportUtils.isSelfDM(chatReport);
    let newQuickAction: ValueOf<typeof CONST.QUICK_ACTIONS> = isSelfDM ? CONST.QUICK_ACTIONS.TRACK_MANUAL : CONST.QUICK_ACTIONS.REQUEST_MANUAL;
    if (isScanRequest) {
        newQuickAction = isSelfDM ? CONST.QUICK_ACTIONS.TRACK_SCAN : CONST.QUICK_ACTIONS.REQUEST_SCAN;
    } else if (isDistanceRequest) {
        newQuickAction = isSelfDM ? CONST.QUICK_ACTIONS.TRACK_DISTANCE : CONST.QUICK_ACTIONS.REQUEST_DISTANCE;
    }

2. Otherwise, if we want to set it to track quick action on categorizing/sharing we should set the quickActionReportID here to be always the selfDM
   

   App/src/libs/actions/IOU.ts

   Line 1385 in 6482913

   chatReportID: chatReport.reportID,

                    chatReportID: ReportUtils.findSelfDMReportID() ?? chatReport.reportID,

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We can prepare a test for IOU.trackExpense by simulating categorizing/sharing (by passing a different chat report than the selfDM) and assert that quickAction is properly set (both the action and chatReportID) according to the solution option we follow above.

What alternative solutions did you explore? (Optional)