Chat - App fails to scroll chat to the first unread message in offline mode

[kbecciv]

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.72-0
Reproducible in staging?: y
Reproducible in production?: n
Issue found when executing PR : #41448
Issue reported by: Applause - Internal Team

Action Performed:

1. Navigate to staging.new.expensify.com
2. Start a chat with user B
3. Navigate to the LHN if on mWeb navigate to another chat if on web
4. Send multiple messages from user B to user A until there is a scrollable space meaning the new unread marker would be outside (higher up) the initial view range when the report is opened
5. Wait until the last message sent from user B is delivered to user A
6. Go offline once step 5 is completed
7. Open the chat with user B

Expected Result:

App automatically scrolls to the first unread message

Actual Result:

App fails to scroll user to the first unread message while in offline mode

Workaround:

n/a

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

bandicam.2024-05-14.08-50-51-971.mp4

Bug6479231_1715598774085.Offline_fail_for_mweb.1.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @madmax330 (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open Staging deploy checklist to see the list of PRs included in this release, then work quickly on the following:

1. If you find which PR caused the issue/bug, you can reassign it to the person responsible for it.
   • If the author is OOO or won’t get online before the daily deploy is due, you are responsible for finding the best fix/path forward. Don’t hesitate to ask for help!
2. Try to reproduce the issue, if the bug is on production, remove the DeployBlocker label but stay assigned to fix it (or find out which PR broke it to get help from the author).
   • You can adjust the urgency of the issue to better represent the gravity of the bug.
   • If the issue is super low priority, feel free to un-assign yourself.
   • Be careful with PHP warnings, sometimes it is more complex than just adding a null coalescing operator as they might be uncovering some bigger bug.
   • If it was a one-off issue that requires no action (for example, Bedrock was down or it is a duplicated issue), you can close it.

Remember rule #2: Never un-assign yourself from a real DeployBlocker unless you are 100% sure someone else is assigned and will take care of it.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[kbecciv]

We think that this bug might be related to #wave-collect - Release 1

[Julesssss]

Very likely App instead of web.

I also think this is not an App blocker as this only occurs while offline. Lets get this fixed at a lower priority

[melvin-bot]

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

[ikevin127]

Looking into this as we speak since I authored PR #41448.
Will get back with a response regarding whether this was caused by my PR and if so I'll handle the follow-up.

[ikevin127]

I cannot reproduce this, it works for me with the given steps. I tried offline mode from Troubleshoot and also from browser Networking tab and both works for me on latest main (local dev) (see video below).

Note

It doesn't make much sense that this would be related to my PR as long as the out-of-view message is correctly marked as unread by BE before going offline.

This is why I'm thinking that since this was tested on the staging server where we're currently experiencing BE issues with API's having delays, this could cause the new marker to not be set in the first place. See #42063 for reference (which was also mistaken as a regression of my PR).

Screen.Recording.2024-05-14.at.11.51.16.mov

cc @Julesssss

[ikevin127]

Regardless, we decided to revert the PR -> more context @ #35011 (comment).

[Julesssss]

Thanks for explaining. We'll retest once the site is stable.

[ikevin127]

After thinking about what happens when navigating to a report while online vs offline, I confirm that this was indeed caused by the now-reverted PR and here's why:

1. When opening a report with new messages online, OpenReport API call is triggered.
2. Since I had sortedVisibleReportActions in the useEffect dependency array, when OpenReport succeeds -> sortedVisibleReportActions is updated -> re-running the effect -> scrolling to the new unread marker.
3. The logic was faulty since the effect was working based on (2.) logic.
4. While offline, the OpenReport API call is NOT triggered -> scroll doesn't happen while offline.

Thanks for explaining. We'll retest once the site is stable.

Note

Given that the NewFeature PR was reverted, this issue should be closed since the chat won't scroll anymore because the new feature functionality was reverted.

[melvin-bot]

This issue has not been updated in over 15 days. @JmillsExpensify, @Julesssss eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[ikevin127]

This should be closed since it was reported as regression from PR #41448 which was reverted. So this shouldn't be an issue anymore since the functionality doesn't exist.