Fix: Leave thread chat when has no comment by dukenv0307 · Pull Request #27849 · Expensify/App

dukenv0307 · 2023-09-20T10:17:27Z

Details

New messages on the threads that I can't see on my LHN are not counting toward the unread counter on the app icon

Fixed Issues

$ #27512
PROPOSAL: #27512 (comment)

Tests

On user A, clicked on a thread made by B that already had comments ( but not from yours )
Didn't add any comment
Left the thread
From user B, send a message to that thread
Verify that the unread indicator ( near the app icon ) is not increase

Verify that no errors appear in the JS console

Offline tests

QA Steps

On user A, clicked on a thread made by B that already had comments ( but not from yours )
Didn't add any comment
Left the thread
From user B, send a message to that thread
Verify that the unread indicator ( near the app icon ) is not increase

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Web

web.7.mp4

Mobile Web - Chrome

chrome.3.mp4

Mobile Web - Safari

safari.1.mp4

Desktop

desktop.5.mp4

iOS

ios.3.mp4

Android

android.6.mp4

melvin-bot · 2023-09-20T10:43:10Z

@fedirjh Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

roryabraham · 2023-09-20T13:38:13Z

@dukenv0307 you have conflicts here

fedirjh · 2023-09-20T15:07:19Z

@roryabraham @dukenv0307 I would like to point out that this solution will not fix the previous thread that you opened without commenting , it will just prevent the bug from occurring in the future. The user should re-open all these threads again to fix the unread count completely. However there is a challenge as these reports are not visible in the LHN, making it difficult for the user to locate them.

dukenv0307 · 2023-09-22T02:26:04Z

@fedirjh Not sure if any actions should I take from my side based on your comment? Or should we wait for the internal team to confirm

dangrous · 2023-09-25T05:30:38Z

Hi! Can we fix conflicts on this and get it merged? At least for me, I think it's fine that it won't fix old threads, they won't be super active (and if people follow the other methods to get to them) it'll be either a non-issue or fixed eventually.

dukenv0307 · 2023-09-25T07:22:23Z

Conflict resolved. Please help review the PR again @dangrous @fedirjh

fedirjh · 2023-09-25T08:43:18Z

Reviewing shortly.

fedirjh · 2023-09-25T08:46:26Z

src/pages/home/ReportScreen.js

+            return;
+        }
+
+        if (ReportUtils.isThread(report) && report.notificationPreference === CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN) {


Let's add a comment explaining this hook.

should prefer early return here:

if (!ReportUtils.isThread(report) || report.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN) { return; } Report.leaveRoom(report.reportID, false);

fedirjh · 2023-09-25T08:48:06Z

src/pages/home/ReportScreen.js

+            Report.leaveRoom(report.reportID, false);
+        }
+
+        // eslint-disable-next-line react-hooks/exhaustive-deps


Why didn’t we pass all deps , basically the report ?

I think we should trigger this useEffect once the report loses focus

Agree we don't want to run this whenever any property on the report changes. However, I think we probably want to make sure that the correct report data is used and want to avoid suppressing the lint rule.

So maybe we can workaround the lint rule with something like this:

const isThread = ReportUtils.isThread(report); const isNotificationPreferenceHidden = report.notificationPreference === CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN; const reportID = report.reportID; // When the report screen is unmounted or no longer in focus, and the user has no comments on that thread, call LeaveRoom useEffect(() => { if (isFocused || !isThread || !isNotificationPreferenceHidden) { return; } Report.leaveRoom(reportID, false); }, [isFocused, isThread, isNotificationPreferenceHidden, reportID]);

fedirjh · 2023-09-25T08:52:44Z

src/pages/home/ReportScreen.js

        [report, isLoading, shouldHideReport, isDefaultReport, isOptimisticDelete, userLeavingStatus],
    );

+    useEffect(() => {


Will this hook runs when component unmounts ?

Yes, it will

fedirjh · 2023-09-25T08:56:35Z

src/libs/actions/Report.js

-    if (report.parentReportID) {
-        Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(report.parentReportID), CONST.NAVIGATION.TYPE.FORCED_UP);
-        return;
+    if (shouldNavigate) {


Let's early return before dismissing the modal and keep the other part as it is .

if (!shouldNavigate) { return }

roryabraham · 2023-09-25T15:44:26Z

Excited to review this one as soon as it's ready

roryabraham · 2023-09-25T15:54:28Z

src/pages/home/ReportScreen.js

+            return;
+        }
+
+        if (ReportUtils.isThread(report) && report.notificationPreference === CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN) {


should prefer early return here:

if (!ReportUtils.isThread(report) || report.notificationPreference !== CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN) { return; } Report.leaveRoom(report.reportID, false);

roryabraham · 2023-09-25T15:55:52Z

src/pages/home/ReportScreen.js

+            Report.leaveRoom(report.reportID, false);
+        }
+
+        // eslint-disable-next-line react-hooks/exhaustive-deps


Agree we don't want to run this whenever any property on the report changes. However, I think we probably want to make sure that the correct report data is used and want to avoid suppressing the lint rule.

So maybe we can workaround the lint rule with something like this:

const isThread = ReportUtils.isThread(report); const isNotificationPreferenceHidden = report.notificationPreference === CONST.REPORT.NOTIFICATION_PREFERENCE.HIDDEN; const reportID = report.reportID; // When the report screen is unmounted or no longer in focus, and the user has no comments on that thread, call LeaveRoom useEffect(() => { if (isFocused || !isThread || !isNotificationPreferenceHidden) { return; } Report.leaveRoom(reportID, false); }, [isFocused, isThread, isNotificationPreferenceHidden, reportID]);

dukenv0307 · 2023-09-26T04:15:48Z

@roryabraham Just updated the code. Please help review again.
Please let me know if any concerns

roryabraham

Nice, LGTM 👍🏼

fedirjh · 2023-09-26T15:12:51Z

src/libs/actions/Report.js

+    if (!shouldNavigate) {
+        return;
+    }


Let's move this line above the modal dismissal .

Bug: User is navigated to concierge after leaving the thread

Open report

Navigate to thread

Click back button

User should go back to main report

User is navigate to concierge

CleanShot.2023-09-26.at.16.07.37.mp4

@fedirjh I see the problem, this PR changed the logic

so I don't think just moving that IF condition will work since when we call LeaveRoom, we set the optimistic data of that report statusNum to CLOSED

App/src/libs/actions/Report.js

Line 1868 in fff2dd4

statusNum: CONST.REPORT.STATUS.CLOSED,

In ReportScreen, we have a logic to navigate to Concierge once statusNum is CLOSED

App/src/pages/home/ReportScreen.js

Lines 312 to 321 in fff2dd4

if (

// non-optimistic case

(!prevUserLeavingStatus && userLeavingStatus) ||

// optimistic case

(prevOnyxReportID && prevOnyxReportID === routeReportID && !onyxReportID && prevReport.statusNum === CONST.REPORT.STATUS.OPEN && report.statusNum === CONST.REPORT.STATUS.CLOSED)

) {

Navigation.goBack();

Report.navigateToConciergeChat();

return;

}

Working on this to find a solution

I think one simple solution for this bug is that we add an optimistic prop let's say shouldNavigate and use it to prevent redirection inside ReportScreen.

optimisticData: [ { onyxMethod: Onyx.METHOD.SET, key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`, value: { stateNum: CONST.REPORT.STATE_NUM.SUBMITTED, statusNum: CONST.REPORT.STATUS.CLOSED, shouldNavigate, // Add this prop }, }, ], // Update the condition to if ( // non-optimistic case (!prevUserLeavingStatus && userLeavingStatus) || // optimistic case (... && report.shouldNavigate) ) {

fedirjh · 2023-10-01T21:19:26Z

@dukenv0307 any update ?

dukenv0307 · 2023-10-02T01:38:05Z

@fedirjh The bug

Bug: User is navigated to concierge after leaving the thread

will be successfully resolved using your suggestion

However, I just encountered a new bug.

A user goes to the thread and clicks on the header of that report
The detail won't appear

Screen.Recording.2023-09-28.at.15.21.58.mov

The reason is that isFocused now will be false, therefore LeaveRoom will be triggered. I need a little bit more time to find a better alternative solution. Will ping back if any update

fedirjh · 2023-10-05T17:40:50Z

The reason is that isFocused now will be false, therefore LeaveRoom will be triggered. I need a little bit more time to find a better alternative solution. Will ping back if any update

@dukenv0307 Why do we prefer leaving the room when the component loses focus, why we didn’t just leave the room when the component unmounts? That way LeaveRoom will be called once.

useEffect(() => () => {
    if (!isThread || !isNotificationPreferenceHidden) {
        return;
    }
    Report.leaveRoom(reportID, false);
}, [isThread, isNotificationPreferenceHidden, reportID]);

dukenv0307 · 2023-10-06T04:30:56Z

@fedirjh
I don't think using the cleanup function here will work since when navigating between screen reports, let's say A to B, screen A is not actually unmounted, in fact, A and B will be pushed to stack as we use react-navigation ( you can refer to this docs ), as a result, cleanup function will not run here.
That is why I wrote the logic in the effect body instead of the cleanup function, and isFocused initially to check whether we navigate out of that report

garrettmknight · 2023-10-11T20:11:39Z

@roryabraham / @fedirjh can you take a look at the failed checks on this one?

roryabraham · 2023-10-12T03:00:19Z

Looks like we have conflicts here, and the last failing check is just the reviewer checklist. Currently awaiting approval + checklist from @fedirjh

dukenv0307 · 2023-10-12T10:48:22Z

@fedirjh @roryabraham After implementing the proposal, I found out that many regressions are likely to happen if the LeaveRoom solution is applied

When we are in a thread A, then we click reply in the thread

We call leaveRoom here, then we will navigate to a new report B but we have no way to navigate back to the parent report when clicking the From in the header
We don't call LeaveRoom here, if other users send a new message to that thread, the unread indicator is still increased

I would suggest applying a new solution to update the logic here

App/src/libs/UnreadIndicatorUpdater/index.js

Lines 11 to 12 in 6c7ee53

    
           const unreadReports = _.filter(reportsFromOnyx, ReportUtils.isUnread); 
        
           updateUnread(_.size(unreadReports));

to leave out all the report that notificationPreference is hidden.
Please let me know if any concerns.

fedirjh · 2023-10-12T17:39:19Z

When we are in a thread A, then we click reply in the thread
We call leaveRoom here, then we will navigate to a new report B but we have no way to navigate back to the parent report when clicking the From in the header
We don't call LeaveRoom here, if other users send a new message to that thread, the unread indicator is still increased

Those are very bad regressions, worse than having wrong indicator 😕 .

to leave out all the report that notificationPreference is hidden.
to leave out all the report that notificationPreference is hidden.

@dukenv0307 Do you suggest we exclude the hidden notificationPreference in the count, But we will still have data in Onyx for those reports. The solution looks better than having wrong count, but doesn’t seems ideal. Curious about your thoughts @roryabraham

dukenv0307 · 2023-10-16T09:49:17Z

@roryabraham Friendly bump. Any thoughts on this #27849 (comment)
cc @fedirjh

roryabraham · 2023-10-18T17:59:46Z

My thoughts are that the solution we are working on here is still logically sound, but we need to add some additional logic to correctly handle edge cases. psuedocode like this:

function maybeLeaveThread:
  if isNavigatingAwayFromThread:
    if didCommentInThread:
      do nothing
    else:
      if isNavigatingToChildThread:
        do nothing
      else:
        leave thread

        # recursively do the same thing for parent threads as well
        if hasParentThread:
          maybeLeaveThread(parentThread)

In plain English, if you navigate away from a thread that you have not commented on, and are not navigating to a child thread, then leave the thread and recursively do the same thing for all parent threads.

thoughts?

fedirjh · 2023-10-25T18:59:56Z

My thoughts are that the solution we are working on here is still logically sound, but we need to add some additional logic to correctly handle edge cases.

@roryabraham Actually, these are not really few edge cases; the report screen will lose focus in different ways, Opening any RHN modal including deeplink will make the report screen lose focus (and trigger the leave action). I am not sure if we can cover all of them with the suggested approach.

fedirjh · 2023-10-26T20:04:47Z

@roryabraham @dukenv0307 We have this PR #30013 merged, It addresses the same issue we are fixing. What is our next plan of action for this PR? Should we proceed with closing it?

roryabraham · 2023-10-26T22:21:56Z

Yes, I suppose we should close this now

dukenv0307 added 2 commits September 20, 2023 15:31

leave room when has no comment

08337c3

fix: merge main

844752d

dukenv0307 marked this pull request as ready for review September 20, 2023 10:43

dukenv0307 requested a review from a team as a code owner September 20, 2023 10:43

melvin-bot bot requested review from fedirjh and removed request for a team September 20, 2023 10:43

merge main

1555286

fix: resolve conflict

3a8f8f0

fedirjh reviewed Sep 25, 2023

View reviewed changes

add comment

475a7e0

roryabraham self-requested a review September 25, 2023 15:44

roryabraham requested changes Sep 25, 2023

View reviewed changes

add dependencies to useEffect

6269ba7

roryabraham approved these changes Sep 26, 2023

View reviewed changes

fedirjh suggested changes Sep 26, 2023

View reviewed changes

roryabraham closed this Oct 26, 2023

	if (
	// non-optimistic case
	(!prevUserLeavingStatus && userLeavingStatus) \|\|
	// optimistic case
	(prevOnyxReportID && prevOnyxReportID === routeReportID && !onyxReportID && prevReport.statusNum === CONST.REPORT.STATUS.OPEN && report.statusNum === CONST.REPORT.STATUS.CLOSED)
	) {
	Navigation.goBack();
	Report.navigateToConciergeChat();
	return;
	}

Conversation

dukenv0307 commented Sep 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Details

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot bot commented Sep 20, 2023

Uh oh!

roryabraham commented Sep 20, 2023

Uh oh!

fedirjh commented Sep 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dukenv0307 commented Sep 22, 2023

Uh oh!

dangrous commented Sep 25, 2023

Uh oh!

dukenv0307 commented Sep 25, 2023

Uh oh!

fedirjh commented Sep 25, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roryabraham Sep 25, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roryabraham commented Sep 25, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roryabraham Sep 25, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dukenv0307 commented Sep 26, 2023

Uh oh!

roryabraham left a comment

Choose a reason for hiding this comment

Uh oh!

fedirjh Sep 26, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dukenv0307 Sep 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fedirjh Sep 27, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fedirjh commented Oct 1, 2023

Uh oh!

dukenv0307 commented Oct 2, 2023

Uh oh!

fedirjh commented Oct 5, 2023

Uh oh!

dukenv0307 commented Oct 6, 2023

dukenv0307 commented Sep 20, 2023 •

edited

Loading

fedirjh commented Sep 20, 2023 •

edited

Loading

roryabraham Sep 25, 2023 •

edited

Loading

roryabraham Sep 25, 2023 •

edited

Loading

fedirjh Sep 26, 2023 •

edited

Loading

dukenv0307 Sep 27, 2023 •

edited

Loading

fedirjh Sep 27, 2023 •

edited

Loading