[$500] Workspace - Infinite skeleton loading when member is removed from Workspace

[lanitochka17]

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: 1.4.36-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers): gocemate@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

1. User A creates Workspace> Members> Invite User B
2. Login as User B and navigate to Announce room
3. User A removes User B

Expected Result:

Announce room should be archived

Actual Result:

Infinite skeleton loading when member is removed from Workspace

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

Bug6365844_1706961916414.Gravar__2034.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01562b797682c4ff91
• Upwork Job ID: 1753799520257306624
• Last Price Increase: 2024-02-10
• Automatic offers:
• aimane-chnaif | Contributor | 0

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @dylanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[lanitochka17]

We think that this bug might be related to #wave6
CC @greg-schroeder

[Amoralchik]

Proposal

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

The issue at hand revolves around the persistence of wasReportAccessibleRef.current as true despite the modification of the report's state.

What is the root cause of that problem?

The core problem stems from the oversight of not updating wasReportAccessibleRef.current to false when the specified condition indicates that the report is inaccessible.

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

To resolve this issue, I propose implementing a correction in the code. Specifically, by introducing the following adjustment in the useEffect block:

useEffect(() => {
    if (!report || !report.reportID || shouldHideReport) {
        wasReportAccessibleRef.current = false;
        return;
    }
    wasReportAccessibleRef.current = true;
}, [shouldHideReport, report]);

This change ensures that wasReportAccessibleRef.current accurately reflects the accessibility state based on the specified conditions.

What alternative solutions did you explore? (Optional)

[dukenv0307]

Proposal

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

• Workspace - Infinite skeleton loading when member is removed from Workspace

What is the root cause of that problem?

• After removing user B, in user B device, it will set the current report to null so the isReportReadyForDisplay is false.

• In ReportScreen, we display the "loading indicator" because the isReportReadyForDisplay is false and shouldShowNotFoundPage is false (If shouldShowNotFoundPage is true, it will display the FullPageNotFoundView rather than "loading indicator":

• Additionally, shouldShowNotFoundPage is false because wasReportAccessibleRef is set to true in the below:
  

  App/src/pages/home/ReportScreen.js

  Lines 282 to 287 in 0ae07be

  	useEffect(() => {
  	if (!report || !report.reportID || shouldHideReport) {
  	return;
  	}
  	wasReportAccessibleRef.current = true;
  	}, [shouldHideReport, report]);

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

• We can display the FullPageNotFoundView in this case. Do it by creating a ref called wasPolicyAnnounceAccessibleButNotNowRef = useRef(false) (This is used to track if the report that has report.chatType === "policyAnnounce" was accessible but now is not) and update it to true in the below logic:

 const prevPolicy = usePrevious(policy);
 const accessibleReport = useRef();
 useEffect(() => {
        if (accessibleReport.current && accessibleReport.current.chatType === CONST.REPORT.CHAT_TYPE.POLICY_ANNOUNCE && wasReportAccessibleRef.current && !wasPolicyAnnounceAccessibleButNotNowRef.current) {
            if (isEmpty(policy) && !isEmpty(prevPolicy)) {
                wasPolicyAnnounceAccessibleButNotNowRef.current = true;
            }
        }
    }, [prevReport.reportID, wasReportAccessibleRef, wasPolicyAnnounceAccessibleButNotNowRef, policy, prevPolicy]);

• Then, update the shouldShowNotFoundPage to:

   const shouldShowNotFoundPage = useMemo(
        () =>
            (!wasReportAccessibleRef.current &&
                !firstRenderRef.current &&
                !report.reportID &&
                !isOptimisticDelete &&
                !reportMetadata.isLoadingInitialReportActions &&
                !isLoading &&
                !userLeavingStatus) ||
            shouldHideReport ||
+         wasPolicyAnnounceAccessibleButNotNowRef.current,
        [report, reportMetadata, isLoading, shouldHideReport, isOptimisticDelete, userLeavingStatus],
    );

• Beside policyAnnounce, we can do the same with other chat type

What alternative solutions did you explore? (Optional)

• NA

[dylanexpensify]

@parasharrajat can you review proposals?

[dylanexpensify]

@zanyrenney curious what you think of this for wave8?