CRITICAL [UX Reliability] Tracking issue for random unreads in LHN

[muttmuure]

Problem

We're seeing a lot of transaction or report threads being made unread in the LHN - we need to deep dive into why that is and fix it.

Solution

Let's track all of the reports of unexpected unreads in the LHN in this issue and keep this issue open until we get to the bottom of it and fix all instances of this bug.

[melvin-bot[bot]]

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

[mallenexpensify]

@muttmuure , do you want to link them in the OP or are the mentions above enough for tracking purposes?

[muttmuure]

I think the mentions are fine

[muttmuure]

No update yet - we're working through them

[mallenexpensify]

New chats not loading or showing in LHN @muttmuure do you want the above added here? It might be the opposite, where unread chats aren't showing.

[puneetlath]

So we've got a few known issues that we're tackling:

• Better handling for the "pre-existing report" case: https://github.com/Expensify/App/issues/45035
• Issue where exporting a report as a copilot marks it as unread when it shouldn't: https://github.com/Expensify/App/issues/44693
• Filtering payroll and bill reports from the LHN: https://github.com/Expensify/App/issues/45104
• Archived chats showing up as unread: https://expensify.slack.com/archives/C05LX9D6E07/p1720624906101939?thread_ts=1720290639.217409&cid=C05LX9D6E07

[deetergp]

Investigations are ongoing.

[muttmuure]

Latest update was here: https://expensify.slack.com/archives/C05LX9D6E07/p1720799600873919

[melvin-bot[bot]]

@deetergp @muttmuure this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[deetergp]

The PR to prevent sending updates to paycheck and bill reports was approved and merged on Tuesday afternoon. @puneetlath and I identified another situation where we might be incorrectly marking reports as unread. I'm hoping to have a PR to address that raised later in the day today.

[melvin-bot[bot]]

@deetergp, @muttmuure Huh... This is 4 days overdue. Who can take care of this?

[deetergp]

This PR just went out to Auth which catches a number of edge cases around reports becoming unexpectedly unread when they receive ESM supported system messages.

[melvin-bot[bot]]

@deetergp, @muttmuure Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[muttmuure]

@deetergp it seems like we've made some progress on this.

It looks like this is the only issue left with random unreads? https://github.com/Expensify/App/issues/44693

[muttmuure]

Can you give an update on the status of the clean up? Thank you!

[deetergp]

@muttmuure I spent some time on it on Thursday and was able to reproduce this locally with bulk exporting. I was OOO on Friday and am back and going to dig into it further today to see if I can prove or disprove my commit conflict theory.

[deetergp]

I found a pretty big bug where, on reports where multiple users should be receiving updated last read times, we were only ever sending one for the first accountID returned by the query. That went to production around 6:30 AM PDT on the 30th. @puneetlath and I did some testing yesterday and found that we should be including REIMBURSED in the list of ESM supported actions. I made a PR for it that was merged earlier today, but has not yet been deployed to production. @twisterdotcom opened a GH earlier today about reports going unread because of POLICYCHANGELOG actions being added, but each one of them happened before the big bugfix went out. I've left the GH open and made it weekly since we are in a wait-and-see pattern at this point.

[muttmuure]

Latest investigations are in this thread: https://expensify.slack.com/archives/C05LX9D6E07/p1722550695230219?thread_ts=1722533224.423589&cid=C05LX9D6E07

[muttmuure]

Not overdue

[deetergp]

Last week, we figured out that everything is finally working correctly on the backend when we bulk export large numbers of reports. Unfortunately, we have also discovered that, despite setting the correct last read times on the backend, and despite queueing them for delivery via Pusher, not everybody is receiving them correctly on the front end. I've started a discussion here to ask for help as I'm not quite sure where to go next with this.

[muttmuure]

This issue is the final report of this happening, so let's close this main tracker in favor of that one