App
App copied to clipboard
HIGH: [UX Reliability] [$500] Random empty chats are showing in LHN in focus mode
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: Reproducible in staging?: needs reproduction Reproducible in production?: needs reproduction If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: @davidcardoza Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1709737869001459
Action Performed:
- Open app and sign in with an account with preference set
focus
- Look at the LHN
Expected Result:
Should not display any random emptychats
Actual Result:
10s of random empty state chats in the LHN, with no way to remove the chats from the LHN view Note: They seems to be the members of the workspace room I am in
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- [ ] Android: Native
- [ ] Android: mWeb Chrome
- [ ] iOS: Native
- [ ] iOS: mWeb Safari
- [x] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
Add any screenshot/video evidence
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~011e45e5cf4631d0fd
- Upwork Job ID: 1768690919242297344
- Last Price Increase: 2024-04-11
- Automatic offers:
- s77rt | Reviewer | 0
- tienifr | Contributor | 0
Triggered auto assignment to @CortneyOfstad (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
I was also experienced this yesterday — getting eyes on this!
Clicking into those blank chats, did remove them, but their creation was unnecessary at least in terms of what I could see in-product
Job added to Upwork: https://www.upwork.com/jobs/~011e45e5cf4631d0fd
Triggered auto assignment to Contributor-plus team member for initial proposal review - @s77rt (External
)
Proposal
Please re-state the problem that we are trying to solve in this issue.
10s of random empty state chats in the LHN, with no way to remove the chats from the LHN view Note: They seems to be the members of the workspace room I am in
What is the root cause of that problem?
In here, if the user is in GSD mode, the "unread" report will always show in LHN, even if it's empty.
That's because the "excluding empty chats" condition is below, in here. So when we detect that the user is in focus mode and the report is unread, we already early return here without considering if the report is empty.
That's why the empty chats will show in LHN in focus mode, but not in default mode.
Now let's look at the isUnread
method to check if the report is unread, we're comparing the lastReadTime
and lastVisibleActionCreated
here, if lastReadTime
is less than lastVisibleActionCreated
, the report is considered unread. However this didn't take into account the case where it's an empty report and the user never read it. In this case lastReadTime
is empty (since the user didn't read it), the lastVisibleActionCreated
will be the time the report is created, so lastReadTime
is always less than lastVisibleActionCreated
and the report is considered unread
, while there's nothing in it to be read.
What changes do you think we should make in order to solve the problem?
We should add non-empty chat check to isUnread
here. The empty chat check logic can be taken from here. This way, we'll make sure only report that is non-empty can be "unread"
What alternative solutions did you explore? (Optional)
There're other ways to check if the report is empty as well, like checking the length of the chat's reportActions
, or check if the reportActions
contains only the report creation action.
Also, an alternative solution is:
- Move the "excluding empty chats" condition here to above the "unread report condition" here.
- We should double check the conditions below the unread condition as well to make sure that's the order we wanted.
@tienifr Thanks for the proposal. Your RCA is not correct.
the "unread" report will always show in LHN, even if it's empty
An empty report should not be considered as unread in the first place (there is nothing unread about it)
@m-natarajan I have a bit of a hard time reproducing this issue. Do you mind sharing a little more about how you achieved this?
Here's what I did to reproduce this issue:
- login
- go to profile -> preferences -> priority mode
- switch priority mode to "#focus"
- return to chat
I do have 3-4 chats with other sub-accounts which are empty. As expected, they are not showing up. Only if I create a new chat I see this one empty. As expected, it is hidden as soon as I leave it.
App Version 1.4.53-2
📣 @jhohlfeld! 📣 Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork. Please follow these steps:
- Make sure you've read and understood the contributing guidelines.
- Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
- Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
- Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>
Contributor details Your Expensify account email: [email protected] Upwork Profile Link: https://www.upwork.com/freelancers/~0137c55e8ae1d137a8
✅ Contributor details stored successfully. Thank you for contributing to Expensify!
@tienifr Thanks for the update. The RCA makes sense and so the solution. Is there a specific case where lastReadTime
is empty? (I'm not able to reproduce the bug)
@tienifr Thanks for the update. The RCA makes sense and so the solution. Is there a specific case where lastReadTime is empty? (I'm not able to reproduce the bug)
@s77rt Please try the following steps:
- Logged in as user A
- Logged in as user B in another browser
- As user B, creates a new empty chat with user A (don't send any message).
- As user A, follows the steps in the OP. The report in
3
will show up in user A side withlastReadTime
empty (because user A never opens that report) -> the bug happens for user A
Not really able to reproduce, always getting the lastReadTime
same as the lastVisibleActionCreated
.
Regarding the unread logic, I have asked in Slack to confirm the expected behaviour in such cases https://expensify.slack.com/archives/C01GTK53T8Q/p1710865076998169
Not really able to reproduce, always getting the lastReadTime same as the lastVisibleActionCreated.
@s77rt Did you make sure not to open the chat as user A? If you opened it at any point in time, the report will have lastReadTime
Yes, I even tried creating a chat while signed out. After signing in I still find lastReadTime
set. Probably getting the report via pusher, not sure why the last read time is set though. In any case we shall confirm the unread expected behaviour maybe it's expected that new chats appear as unread? (slack thread)
In any case we shall confirm the unread expected behaviour maybe it's expected that new chats appear as unread? (slack thread)
@s77rt Looks like everyone agrees that the new chats should not appear.
Probably getting the report via pusher, not sure why the last read time is set though.
I tried again today and it looks like the lastReadTime
is now set randomly, sometimes it's before lastVisibleActionCreated
, sometimes slightly after. It shouldn't be there though since the user didn't read the report at all.
I shouldn't affect the solution here though. Do you think we can move forward?
@tienifr Often the best thing to do is nothing. Perhaps this is no longer reproducible.
@m-natarajan Can you please retest if this is still reproducible from your end?
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
@m-natarajan, based on the comment here, can you test to see if this is still reproducible by EOD? Thanks!
@m-natarajan bump on the above ^^ thanks!
Issue not reproducible during KI retests. (First week)
Can we close this for now and reopen if this resurface again?
Sounds good @s77rt 👍
Can we close this for now and reopen if this resurface again?
@CortneyOfstad Please help reopen this issue, this is occurring again here https://github.com/Expensify/App/issues/39558
cc @s77rt
Agreed. Let's reopen this
@CortneyOfstad Could you help reopen this issue as per discussion above? Thanks!
Sorry about that! Reopening now!
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸