[HOLD for payment 2024-10-16] [$250] Dupe detect - App crashes when leaving Review duplicates page after viewing other expense

[lanitochka17]

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.43-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

1. Launch New Expensify app
2. Go to workspace chat
3. Submit two same expenses
4. Go to transaction thread of any expenses
5. Tap Review duplicates
6. Tap on the second expense preview
7. Swipe right to go back
8. Swipe right again

Expected Result:

App will not crash

Actual Result:

App crashes when leaving Review duplicates page after viewing one of the duplicates

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6622529_1727898403537.ScreenRecording_10-03-2024_03-42-47_1.mp4

logs (2).txt

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021841675705747272356
• Upwork Job ID: 1841675705747272356
• Last Price Increase: 2024-10-03
• Automatic offers:
• jjcoffee | Reviewer | 104265027
• Nodebrute | Contributor | 104265029

Issue Owner

Current Issue Owner: @RachCHopkins

[melvin-bot]

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

[lanitochka17]

@RachCHopkins FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[lanitochka17]

We think that this bug might be related to #wave-control

[Nodebrute]

Edited by proposal-police: This proposal was edited at 2024-10-03 12:09:11 UTC.

Proposal

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

App crashes when leaving Review duplicates page after viewing other expense

What is the root cause of that problem?

Here we attached beforeRemoveReportOpenedFromSearchRHP to beforeRemove

App/src/libs/Navigation/AppNavigator/AuthScreens.tsx

Lines 113 to 119 in 2965b0b

	function getCentralPaneScreenListeners(screenName: CentralPaneName) {
	if (screenName === SCREENS.REPORT) {
	return {beforeRemove: beforeRemoveReportOpenedFromSearchRHP};
	}
	return {};
	}

and in beforeRemoveReportOpenedFromSearchRHP we use goBack. In the case of error we fell in to loop of goBack and beforeRemove. This continuous recursion causes the function to call itself repeatedly, resulting in a "maximum call stack exceeded" error.

App/src/libs/Navigation/AppNavigator/beforeRemoveReportOpenedFromSearchRHP/index.native.ts

Lines 35 to 38 in 2965b0b

	event.preventDefault();
	const bottomTabState = state?.routes?.at(0)?.state;
	navigationRef.dispatch({...StackActions.pop(), target: bottomTabState?.key});
	Navigation.goBack();

It's because shouldPopHome will be true and this will keep calling goBack

App/src/libs/Navigation/AppNavigator/beforeRemoveReportOpenedFromSearchRHP/index.native.ts

Line 25 in b52f1d4

const shouldPopHome =

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

A good solution will be that shouldPopHome should return false in this case.

We added this code to solve this issue

App/src/libs/Navigation/AppNavigator/beforeRemoveReportOpenedFromSearchRHP/index.native.ts

Lines 25 to 33 in b52f1d4

	const shouldPopHome =
	state.routes?.length >= 3 &&
	state.routes.at(-1)?.name === SCREENS.REPORT &&
	state.routes.at(-2)?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR &&
	getTopmostBottomTabRoute(state)?.name === SCREENS.HOME;
	if (!shouldPopHome) {
	return;
	}

But with the steps of this issue shouldPopHome will become true. So to solve this problem we can change this condition

    const shouldPopHome =
        state.routes?.length >= 3 &&
        state.routes.at(-1)?.name === SCREENS.REPORT &&
        state.routes.at(-2)?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR &&
        state.routes.at(-3)?.name === SCREENS.SEARCH.CENTRAL_PANE &&
        getTopmostBottomTabRoute(state)?.name === SCREENS.HOME;

Results

Screen.Recording.2024-10-03.at.5.23.59.AM.mov

Thread navigation is also working as expected

Screen.Recording.2024-10-03.at.5.25.39.AM.mov

What alternative solutions did you explore? (Optional)

We can create a variable

let hasPopped = false;

and then we can use it here

  if (!navigationRef.current || || hasPopped) {
        return;
    }

and then before going back we can set it to true and after goBack we can set it to false

    hasPopped  = true;
    Navigation.goBack();

Alternative 2
We can check here state.routes.at(-3)?.name !== SCREENS.REPORT &&

App/src/libs/Navigation/AppNavigator/beforeRemoveReportOpenedFromSearchRHP/index.native.ts

Line 29 in e0133e5

getTopmostBottomTabRoute(state)?.name === SCREENS.HOME;

[RachCHopkins]

I don't have this button in the TestFlight iOS app which is 41-2. I will just have to assume it's reproducible since we have a proposal already!

[melvin-bot]

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

[melvin-bot]

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

[jjcoffee]

@Nodebrute Thanks for the proposal! I'm wondering why beforeRemoveReportOpenedFromSearchRHP is running at all here, since we don't have the search RHP open in this case. cc @WojtekBoman as you worked on this.

In the case of error we fell in to loop of goBack and beforeRemove

I'm also not sure I understand this. What error are we talking about that's causing the loop?

[Nodebrute]

I'm wondering why beforeRemoveReportOpenedFromSearchRHP is running at all here, since we don't have the search RHP open in this case.

@jjcoffee this is the main rca. We don't check if we are coming from search. This is what the navigation stack looks for opening thread from search

And this is what that navigation stacks looks like with the steps of this issue.

In both above cases this code block will be true cause we don't check if the screen below rightModalNavigator is search.

App/src/libs/Navigation/AppNavigator/beforeRemoveReportOpenedFromSearchRHP/index.native.ts

Lines 25 to 29 in e0133e5

	const shouldPopHome =
	state.routes?.length >= 3 &&
	state.routes.at(-1)?.name === SCREENS.REPORT &&
	state.routes.at(-2)?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR &&
	getTopmostBottomTabRoute(state)?.name === SCREENS.HOME;

We get this error

Screen.Recording.2024-10-03.at.4.51.47.PM.mov

It starts from beforeRemoveReportOpenedFromSearchRHP and traces back to the Lodash library

[Nodebrute]

@jjcoffee My solution is to check if below RIGHT_MODAL_NAVIGATOR we have search. This prevents shouldPopHome from being true in the duplicate review case. I've tested this with several cases, and everything is working fine. Let me know if you have any questions.

[Nodebrute]

@jjcoffee Sorry, I just wanted to add one last thing. When we click review duplicates it is opened in RHP and then we click on the expense to open report, the navigation stack will be the almost same in thread-search case and review duplicates case except we'll have search panel below in thread-search case but we don't check for that in shouldPopHome That's why all the conditions for shouldPopHome will be true.

Screen.Recording.2024-10-03.at.5.00.37.PM.mov

[jjcoffee]

@Nodebrute Thanks for clarifying! My only concern is how much we can rely on state.routes.at(-3)?.name === SCREENS.SEARCH.CENTRAL_PANE, i.e. is it guaranteed that it will always be at that position?

[Nodebrute]

@jjcoffee We can depend on state.routes.at(-3)?.name === SCREENS.SEARCH.CENTRAL_PANE because we only want to pop home when the search panel is belowRIGHT_MODAL_NAVIGATOR. Regardless of how deep we go into the search, when coming back, the stack will remain the same, and we will get the same results.

Screen.Recording.2024-10-03.at.5.17.29.PM.mov

[jjcoffee]

True! That makes sense, thanks for the clarifications. Happy to go with @Nodebrute's proposal here.

🎀👀🎀 C+ reviewed

[melvin-bot]

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

[Nodebrute]

@mjasikowski friendly bump for assignment.

[mjasikowski]

@Nodebrute's proposal looks good, indeed, assigning

[melvin-bot]

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

Offer link
Upwork job

[melvin-bot]

📣 @Nodebrute 🎉 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 📖

[WojtekBoman]

Hey @jjcoffee, I've checked this proposal and it's fine :) shouldPopHome should verify if RHP is opened from SearchPage

[melvin-bot]

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

[melvin-bot]

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

• fix ios crash #50254

If no regressions arise, payment will be issued on 2024-10-16. 🎊

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

• @jjcoffee requires payment automatic offer (Reviewer)
• @Nodebrute requires payment automatic offer (Contributor)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@jjcoffee] The PR that introduced the bug has been identified. Link to the PR:
• [@jjcoffee] 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:
• [@jjcoffee] A discussion in #expensify-bugs 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:
• [@jjcoffee] Determine if we should create a regression test for this bug.
• [@jjcoffee] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@RachCHopkins] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[RachCHopkins]

Payment Summary:

• Contributor: @Nodebrute to be paid $250 via Upwork
• Contributor+: @jjcoffee to be paid $250 via Upwork

Upwork job here

@jjcoffee can you do the checklist above, please?

[RachCHopkins]

Contributors have been paid, the contracts have been completed, and the Upwork post has been closed.

[jjcoffee]

• The PR that introduced the bug has been identified. Link to the PR: [Search v2.1] Android & iOS - Search icon is not responsive after returning to LHN from thread #48990
• 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: https://github.com/Expensify/App/pull/48990/files#r1802620716
• A discussion in #expensify-bugs 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: N/A
• Determine if we should create a regression test for this bug. Yes
• If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression Test Proposal
Mobile-only.

1. Go to any workspace chat
2. Submit two identical expenses
3. Go to the transaction thread of one of the expenses
4. Tap Review duplicates
5. Tap on the second expense preview
6. Swipe right to go back
7. Swipe right again

Do we agree 👍 or 👎

[RachCHopkins]

Thanks @jjcoffee, regression test requested! Closing.