[$250] Chat- Previous messages do not load on rejoining thread & then enabling internet connection

[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: 1.4.60-5 Reproducible in staging?: Y Reproducible in production?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4475785&group_by=cases:section_id&group_order=asc&group_id=291937 Email or phone of affected tester (no customers): [email protected] Issue reported by: Applause - Internal Team

Action Performed:

Precondition : Open 1:1 chat which has several previous messages

1. Navigate to a 1:1 Conversation
2. Start a thread and send some messages
3. Disable the internet connection on thread conversation page
4. Click on the three dot menu and hit "Leave thread"
5. User navigated back to the parent conversation
6. Click on the thread link to rejoin the thread (Note : skeleton loader is displayed since the user is offline)
7. Enable the internet connection

Expected Result:

On enabling internet connection after rejoining thread, thread loads and all the previous messages are displayed

Actual Result:

Previous messages do not load on rejoining thread & then enabling internet connection. Blank chat space is displayed once the user go online

Workaround:

Unknown

Platforms:

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

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

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/16d757cb-938f-4a41-9609-6a5aa189f9ef

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01fa1379d6f9d45105
• Upwork Job ID: 1778440845939150848
• Last Price Increase: 2024-04-11

[melvin-bot[bot]]

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

[lanitochka17]

@CortneyOfstad 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 #vip-vsp

[jacobkim9881]

Proposal

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

At report thread offline exiting the thread shows older chats as skeleton loading.

What is the root cause of that problem?

Opened thread's previousReportActionID gets 0 from BE server for loading old chats. Online, older chats are updated from BE. But previousReportActionID isn't considered when offline.

previousReportActionID is used to sort sortedReportActions. If sortedReportActions should be sorted, then it gets endIndex to sort the array like below,

https://github.com/Expensify/App/blob/db9e01cc302df7f2b3dd53a99c1082404676aedb/src/libs/ReportActionsUtils.ts#L327-L336

But there is no condition when thread is opened/leaved while offline. Without the conditions, sortedReportActions is sorted into olderChats and newerChats. FE should wait for BE response to get olderChats offline.

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

Above conditions, if offline and endIndex is lower than sortedReportActions.length - 1, sortedReportActions should be returned.

We can add from while conditions like below,

   while (
          (endIndex < sortedReportActions.length - 1 && sortedReportActions[endIndex].previousReport	ActionID === sortedReportActions[endIndex + 1].reportActionID) ||
          !!sortedReportActions[endIndex + 1]?.whisperedToAccountIDs?.length ||
          !!sortedReportActions[endIndex]?.whisperedToAccountIDs?.length ||
          sortedReportActions[endIndex]?.actionName === CONST.REPORT.ACTIONS.TYPE.ROOMCHANGELOG.INVITE_TO_ROOM ||
          sortedReportActions[endIndex + 1]?.actionName === CONST.REPORT.ACTIONS.TYPE.CLOSED ||
          sortedReportActions[endIndex + 1]?.actionName === CONST.REPORT.ACTIONS.TYPE.CREATED
      ) {
          endIndex++;
      }

if(isOffline && endIndex < sortedReportActions.length - 1) {
return sortedReportActions
}

So when previousReportActionID is 0 and isOffline then the report actions can wait for response from BE.

What alternative solutions did you explore? (Optional)

If offline, we don't let the app sort report actions based on a condition for previousReportActionID because BE server doesn't response. So unsorted report actions are shown.

https://github.com/Expensify/App/blob/f7b000bd00bcea0c2c45f2ac452964e941d07246/src/pages/home/ReportScreen.tsx#L257

From above, we add condition

const currentRangeOfReportActions = network.isOffline? sortedAllReportActions : ReportActionsUtils.getContinuousReportActionChain(sortedAllReportActions, reportActionIDFromRoute);

[CortneyOfstad]

@lanitochka17 I cannot follow your video — the cursor is moving too fast for me to clearly see what action is being taken. Can you please update the original comment with a different video?

I tried to recreate via the instructions above, but I wasn't able to recreate, so I would like to see a clearer video to see if any steps are unintentionally missed 👍

[roryabraham]

thanks for your proposal @jacobkim9881, but I think the root cause of this bug is that previousReportActionID is being set to 0. That should only ever be true for reportActions w/ type CREATED

[jacobkim9881]

@roryabraham Thanks for helping me identifying the root cause.

Could you review my solution too? Importing useNetwork on App/src/pages/home/ReportScreen.tsx could be heavy or passing for waiting BE response offline could bring any side effects?

[jacobkim9881]

@roryabraham previousReportActionID's0 is used for identifying opened thread for this case. BE server should response with updated value but FE only waiting for the response. I wonder why failure response doesn't happened so to load not updated older chats.

[jacobkim9881]

The case previousReportActionID = '0` isn't considered on some code.

Older chats are loaded by this,

https://github.com/Expensify/App/blob/260a7de64b083e82d3a79ad8b48d94b4a32885c2/src/pages/home/report/ReportActionsView.tsx#L342

If offline then above function isn't called because of this,

https://github.com/Expensify/App/blob/260a7de64b083e82d3a79ad8b48d94b4a32885c2/src/pages/home/report/ReportActionsView.tsx#L323

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[CortneyOfstad]

@akinwale There is a proposal here from @jacobkim9881. @roryabraham provided some feedback, but if you have any input as well, please share — thanks!

[akinwale]

@jacobkim9881 Could you update your proposal with the correct root cause and verify that the solution actually fixes the issue?

[jacobkim9881]

Proposal

Updated

[lanitochka17]

@CortneyOfstad Tried to reproduce the issue several times. It repeats itself every other time.

https://github.com/Expensify/App/assets/78819774/957e1c31-bb76-4d95-a133-91a926015b72

[CortneyOfstad]

@akinwale there is an update to the proposal here 👍

[akinwale]

@jacobkim9881 Thank you for the update. Could you create a short video demonstrating the proposed fix?

[jacobkim9881]

@akinwale It isn't reproducible for now. As BE reponse previousReportActionID gets different value not 0. Seems BE updated response for previousReportActionID. As a FE contributor, I can't access related information 😟

[CortneyOfstad]

@lanitochka17 can you confirm if this issue is still happening?

[lanitochka17]

@CortneyOfstad Not reproducible now. Skeleton loader does not appear & all messages displayed as expected after leave/Join thread with or without internet

https://github.com/Expensify/App/assets/78819774/d3f97db5-67ef-472d-93fa-38eef9e3c99b

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[CortneyOfstad]

Since this is not reproducible, going to close — thanks!