[Due for payment 2025-04-17] [$250] Room - Infinite loading when user is removed from room while in RHP

[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.1.11-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5725070&group_by=cases:section_id&group_order=asc&group_id=296763
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 - Android 12 - Chrome / Windows 10 - Chrome
App Component: Other

Action Performed:

Prerequisite: Have two accounts, opened in two different devices or environments.

1. Open the staging.new.expensify,com website.
2. Open any private room chat or create one if necessary.
3. Tap on room header and select "Members"
4. Invite another user to the room.
5. Switch to User B account.
6. Open the room and tap on the header.
7. While User B stays on RHP, switch to User A account again.
8. Tap on room header and select "Members"
9. Remove User B from room chat.
10. Switch to User B account again.
11. Note that a "It´s not here" screen is displayed.
12. Tap on the arrow on the top left corner.
13. Check the app´s behaviour when returning to chat.

Expected Result:

Removed User should see the "It's not here" screen, and then tapping on the back button at the top of that screen should return them to their chat/LHN.

Actual Result:

Removed User taps on the back button at the top of the "It's not here" screen, and infinite loading is experienced when returning to chat/LHN.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6767494_1741702674511.Not_Here.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021900277799378678085
• Upwork Job ID: 1900277799378678085
• Last Price Increase: 2025-03-20
• Automatic offers:
• thelullabyy | Contributor | 106615459

Issue Owner

Current Issue Owner: @lydiabarclay

[melvin-bot]

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

[Themoonalsofall]

Proposal

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

Using device back button after deleting workspace, leads to "It´s not here" page

What is the root cause of that problem?

After we delete the workspace, we'll navigate to SETTINGS_WORKSPACES route

App/src/libs/PolicyUtils.ts

Lines 522 to 524 in b239a9b

	function goBackFromInvalidPolicy() {
	Navigation.navigate(ROUTES.SETTINGS_WORKSPACES.route);
	}

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

We should use goBack to prevent go back to the previous page if user use device back button

Navigation.goBack(ROUTES.SETTINGS_WORKSPACES);

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

None

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.

[thelullabyy]

Proposal

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

• When a member of a private room is removed while staying on RHP, a "It´s not here" screen is displayed, and infinite loading is experienced when returning to chat.

What is the root cause of that problem?

• When the current user is removed from a room, we already have logic to redirect them to the Concierge chat. However, if the user is opening the report detail page at that moment, the navigation logic is skipped:

App/src/pages/home/ReportScreen.tsx

Lines 542 to 546 in 67cb4c1

	// Early return if the report we're passing isn't in a focused state. We only want to navigate to Concierge if the user leaves the room from another device or gets removed from the room while the report is in a focused state.
	// Prevent auto navigation for report in RHP
	if (!isFocused || isInNarrowPaneModal) {
	return;
	}

• As a result, the loading indicator remains on the report screen:

App/src/pages/home/ReportScreen.tsx

Line 741 in 67cb4c1

<ReportActionsSkeletonView />

Eventually, the "It's not here" message appears in the report detail.

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

• When the report screen is not focused, we should avoid skipping this logic if a report detail screen is open in the RHP and its reportID matches the reportID of the report screen.

            const currentRoute = navigationRef.getCurrentRoute();
            const isReportDetailOpenInRHP =
                isTopMostReportId &&
                [...Object.values(SCREENS.REPORT_DETAILS), ...Object.values(SCREENS.REPORT_SETTINGS), ...Object.values(SCREENS.PRIVATE_NOTES)].includes(currentRoute?.name ?? '') &&
                reportIDFromRoute === currentRoute?.params?.reportID;
            // Early return if the report we're passing isn't in a focused state. We only want to navigate to Concierge if the user leaves the room from another device or gets removed from the room while the report is in a focused state.
            // Prevent auto navigation for report in RHP
            if ((!isFocused && !isReportDetailOpenInRHP) || isInNarrowPaneModal) {

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

• Implement a utility function to check if isReportDetailOpenInRHP. Ensure this function returns true in the scenario where the bug occurs — specifically, when a report is opened, and its detail screen is accessed by tapping the header.

What alternative solutions did you explore? (Optional)

• The core value in the main solution:

const isReportDetailOpenInRHP =
                isTopMostReportId &&
                [...Object.values(SCREENS.REPORT_DETAILS), ...Object.values(SCREENS.REPORT_SETTINGS), ...Object.values(SCREENS.PRIVATE_NOTES)].includes(currentRoute?.name ?? '') &&
                reportIDFromRoute === currentRoute?.params?.reportID;

can be simplified by dropping the route name check:

[...Object.values(SCREENS.REPORT_DETAILS), ...Object.values(SCREENS.REPORT_SETTINGS), ...Object.values(SCREENS.PRIVATE_NOTES)].includes(currentRoute?.name ?? '')

This way, as long as the RHP screen has a reportID param matching the reportID of the removed report, we ensure the navigation to Concierge isn’t skipped.

• Alternatively, we can consider dropping other factors based on our discussion about the expected behavior, keeping only the essential checks to ensure the navigation logic works correctly without unnecessary conditions.

[lydiabarclay]

Waiting for some clarification in slack before proceeding with triage (possibly update "expected result" section)

[lydiabarclay]

• Confirmed that the "hmm... it's not here" screen is expected and desired behavior, however the infinite loading is not
• They should get punted back to their Left Hand Nav instead of seeing infinite loaders when they tap the back button at the top of the "hmm... it's not here screen"
• Updating title and expected result section.

[melvin-bot]

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

[melvin-bot]

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

[thelullabyy]

@lydiabarclay In the case of a large device, when the user opens the RHP, which report will be visible in the background?

[lydiabarclay]

@thelullabyy can you clarify your question a little? for example, are you asking whether the removed user should see the "it's not here" screen on both desktop and mobile? I'm a little confused by what you mean by "which report."

[thelullabyy]

• The expected behavior described in this OP only covers mobile devices, not desktop. @lydiabarclay I’m curious about the expected behavior on desktop, specifically in steps 11 and 13 of the test case below:

Prerequisite:

Two accounts, each logged into a different device or environment.
User B uses a large screen device (e.g., desktop).

1. Open the staging.new.expensify,com website.
2. Open any private room chat or create one if necessary.
3. Tap on room header and select "Members"
4. Invite another user to the room.
5. Switch to User B account.
6. Open the room and tap on the header.
7. While User B stays on RHP, switch to User A account again.
8. Tap on room header and select "Members"
9. Remove User B from room chat.
10. Switch to User B account again.
11. Note that a "It´s not here" screen is displayed in RHP. And there is a infinite loading screen in the background.
12. Tap on the arrow on the top left corner.
13. The RHP is closed, but the infinite loading screen is still showing.

• FYI: When User B has a report open and gets removed from it by an admin, the existing logic should redirect them to the Concierge report. However, this only works if the active screen is the report screen. We can verify this behavior with the following test case:

1. Open the staging.new.expensify,com website.
2. Open any private room chat or create one if necessary.
3. Tap on room header and select "Members"
4. Invite another user to the room.
5. Switch to User B account.
6. Open the room.
7. Switch to User A account again.
8. Tap on room header and select "Members"
9. Remove User B from room chat.
10. Switch to User B account again.
11. Note that user B is navigated to Concierge.

In this bug, since the opening screen is the report detail, the report screen just remains in the background. As a result, User B isn’t redirected to the Concierge report when removed by User A. I think we could leverage the existing behavior (redirecting the user to the Concierge report when they’re removed from a room) to fix this bug too. What do you think, @lydiabarclay?

[melvin-bot]

@allroundexperts Whoops! This issue is 2 days overdue. Let's get this updated quick!

[lydiabarclay]

@shawnborton could you advise on the above suggestion?

[shawnborton]

At this point here, I think I would just direct the user back to the LHN:

But I didn't realize we were sending the user to Concierge in other cases, so if that's the established pattern, let's do that here too right?

[shawnborton]

cc @Expensify/design for viz

[dannymcclain]

Yeah I agree with Shawn. I would expect to go back to the LHN after that screen, but also agree that if we have an established pattern let's just stick with it.

[lydiabarclay]

@thelullabyy confirmed above!

[lydiabarclay]

@thelullabyy will you update your proposal if needed?

[lydiabarclay]

@allroundexperts will you review proposals?

[melvin-bot]

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

[melvin-bot]

📣 @thelullabyy 🎉 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]

@allroundexperts Whoops! This issue is 2 days overdue. Let's get this updated quick!

[lydiabarclay]

@thelullabyy could you please update the issue on when we can expect a PR to be ready for review

[thelullabyy]

@lydiabarclay Sorry about the delay, it'll be ready today

[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.1.25-4 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Room - Infinite loading when user is removed from room while in RHP #59126

If no regressions arise, payment will be issued on 2025-04-17. 🎊

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

• @allroundexperts requires payment through NewDot Manual Requests
• @thelullabyy requires payment automatic offer (Contributor)

[melvin-bot]

@allroundexperts @lydiabarclay @allroundexperts 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]

[lydiabarclay]

@allroundexperts will you please complete the checklist? Thanks so much!

[allroundexperts]

BugZero Checklist:

• [Contributor] 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:

• [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: I was unable to pinpoint an exact PR that caused this. It looks like this behaviour existed since we implemented the above mentioned redirect logic.

• [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: N/A

• [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.

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

  Link to issue: https://github.com/Expensify/Expensify/issues/491128

Regression Test Proposal

Precondition:

• Have two accounts, opened in two different devices or environments.

Test:

1. Open any private room chat or create one if necessary.
2. Tap on room header and select "Members"
3. Invite another user to the room.
4. Switch to User B account.
5. Open the room and tap on the header.
6. While User B stays on RHP, switch to User A account again.
7. Tap on room header and select "Members"
8. Remove User B from room chat.
9. Switch to User B account again.
10. Note that a "It´s not here" screen is displayed.
11. Tap on the arrow on the top left corner.
12. Check the app´s behaviour when returning to chat.

Verify that the removed User should see the "It's not here" screen, and then tapping on the back button at the top of that screen should return them to their chat/LHN.

Do we agree 👍 or 👎

[lydiabarclay]

Payment Summary

Contributor: @thelullabyy paid $250 via Upwork
Contributor+: @allroundexperts requires payment through NewDot Manual Requests

...

Paid, regression test filed: https://github.com/Expensify/Expensify/issues/491128