[$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 [email protected] 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): [email protected] 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:

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

Screenshots/Videos

https://github.com/user-attachments/assets/e8ccfcb4-a7d7-4643-8b46-40e8cb961860

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-09

Issue Owner

Current Issue Owner: @eVoloshchak

[melvin-bot[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[bot]]

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

[melvin-bot[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 https://github.com/Expensify/App/blob/64829131fe962681626b4b016140521d05f7fe52/src/libs/actions/IOU.ts#L1381-L1386 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 https://github.com/Expensify/App/blob/64829131fe962681626b4b016140521d05f7fe52/src/libs/actions/IOU.ts#L1359-L1364

 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 https://github.com/Expensify/App/blob/64829131fe962681626b4b016140521d05f7fe52/src/libs/actions/IOU.ts#L1385

                    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)

[isabelastisser]

@eVoloshchak, please review the updated proposal above? Thanks!

[melvin-bot[bot]]

@eVoloshchak, @isabelastisser Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[isabelastisser]

@eVoloshchak, please provide an update. Thanks!

[isabelastisser]

@eVoloshchak, I DM'd you for visibility. 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]]

@eVoloshchak, @isabelastisser 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[eVoloshchak]

@FitseTLT's proposal looks good to me! The second option seems to be more universal, let's proceed with that

🎀👀🎀 C+ reviewed!

[melvin-bot[bot]]

Triggered auto assignment to @jasperhuangg, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[FitseTLT]

@jasperhuangg please suggest the option we should follow here. IMO option 1 is correct (categorize/share are more or less the same as creating expense than tracking expense) and @eVoloshchak chose 2. let's know your thoughts.

[melvin-bot[bot]]

@eVoloshchak @isabelastisser @jasperhuangg 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!

[isabelastisser]

Hey @jasperhuangg, can you please share an update? Thanks!

[melvin-bot[bot]]

@eVoloshchak, @isabelastisser, @jasperhuangg Huh... This is 4 days overdue. Who can take care of this?

[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? 💸

[jasperhuangg]

Yeah, I agree that the first option is more intuitive to me. Categories are only available when you request money from a workspace, so categorizing an expense is the same as requesting money on that workspace. Let's move forward with your first approach. @FitseTLT Thanks for asking!

[FitseTLT]

Yeah, I agree that the first option is more intuitive to me. Categories are only available when you request money from a workspace, so categorizing an expense is the same as requesting money on that workspace. Let's move forward with your first approach. @FitseTLT Thanks for asking!

Ok don't forget to assign me 👍

[melvin-bot[bot]]

📣 @FitseTLT 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻 Keep in mind: Code of Conduct | Contributing 📖

[melvin-bot[bot]]

This issue has not been updated in over 15 days. @eVoloshchak, @isabelastisser, @jasperhuangg, @FitseTLT 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!

[FitseTLT]

@eVoloshchak Are you able to review the PR? please let us know so that we can reassign Thx.

cc @isabelastisser

[isabelastisser]

@eVoloshchak, can you please follow up on the question above? Thanks!

[FitseTLT]

Bump @eVoloshchak

[melvin-bot[bot]]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot[bot]]

The solution for this issue has been :rocket: deployed to production :rocket: in version 9.1.6-1 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

• https://github.com/Expensify/App/pull/54410

If no regressions arise, payment will be issued on 2025-03-05. :confetti_ball:

For reference, here are some details about the assignees on this issue:

• @eVoloshchak requires payment through NewDot Manual Requests
• @FitseTLT requires payment automatic offer (Contributor)

[melvin-bot[bot]]

@eVoloshchak @isabelastisser @eVoloshchak The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[isabelastisser]

BugZero Checklist:

• [ ] @eVoloshchak Classify the bug:

Bug classification

Source of bug:

• [ ] 1a. Result of the original design (eg. a case wasn't considered)
• [ ] 1b. Mistake during implementation
• [ ] 1c. Backend bug
• [ ] 1z. Other:

Where bug was reported:

• [ ] 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• [ ] 2b. Reported on staging (eg. found during regression or PR testing)
• [ ] 2d. Reported on a PR
• [ ] 2z. Other:

Who reported the bug:

• [ ] 3a. Expensify user
• [ ] 3b. Expensify employee
• [ ] 3c. Contributor
• [ ] 3d. QA
• [ ] 3z. Other:

• [ ] @eVoloshchak The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment:

• [ ] @eVoloshchak If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion:

• [ ] @eVoloshchak If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

• [ ] @isabelastisser Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

Precondition:

Test:

Do we agree 👍 or 👎

[isabelastisser]

@eVoloshchak @FitseTLT, is this ready for payment?

@eVoloshchak, please complete the checklist above. Thanks!

[eVoloshchak]

BugZero Checklist:

• [x] [Contributor] Classify the bug:

Bug classification

Source of bug:

• [x] 1a. Result of the original design (eg. a case wasn't considered)
• [ ] 1b. Mistake during implementation
• [ ] 1c. Backend bug
• [ ] 1z. Other:

Where bug was reported:

• [x] 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
• [ ] 2b. Reported on staging (eg. found during regression or PR testing)
• [ ] 2d. Reported on a PR
• [ ] 2z. Other:

Who reported the bug:

• [ ] 3a. Expensify user
• [ ] 3b. Expensify employee
• [ ] 3c. Contributor
• [x] 3d. QA
• [ ] 3z. Other:

• [x] [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

  Link to comment: this is a case that wan't considered initially, there is not PR that has caused this bug

• [x] [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

  Link to discussion: regression was not critical

• [x] [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Regression Test Proposal Template

• [ ] [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.

  Link to issue:

Regression Test Proposal

=

Test:

1. Go to self DM.
2. Track a manual expense.
3. Click Categorize it.
4. Select a category, enter merchant and submit the expense to the workspace.
5. Open FAB.
6. Verify that the quick action is create expense with the workspace in step (4)
7. Click Quick action
8. Verify that URL is .../create/submit/... not .../create/track...
9. enter amount create the expense
10. Verify that the expense is created for the workspace in step (4)

Do we agree 👍 or 👎