App
App copied to clipboard
BUG: Loading chat preview stuck after creating new chat while offline
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Action Performed:
- Log into Expensify on desktop with Device A
- On Device B, any platform, log in to another account that has never chatted with account on device A
- Disable your internet connection on Device A. WiFi > OFF
- On Device B, send a message to the account logged in device A
- On Device A, navigate to LHN (mobile) or to another conversation (Desktop/Web)
- Enable the internet connection on Device A.
- Ensure the message you sent via Device B is received on Device A
- Disable the internet connection on Device A
- Click/tap on the bold chat in LHN in Device A
Expected Result:
Chat should load despite being offline and look like a normal chat
Actual Result:
Chat is loading, but grey loading chat screen is stuck and will not go away after going back online or refreshing app
Workaround:
unknown
Platform:
Where is this issue occurring?
- Web
Version Number: 1.2.18-7 Reproducible in staging?: y Reproducible in production?: y Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/197409423-e292c80c-a09c-464d-939b-11ddde625d46.mp4
https://user-images.githubusercontent.com/43996225/197409444-043ea75f-b57e-449a-879e-c502d3feac60.mov
Expensify/Expensify Issue URL: Issue reported by: @grgia Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1666395031582879
Triggered auto assignment to @mallenexpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.
Problem: Issue is caused by this prop here in InvertedFlat list. Since we are removing the Skeleton effect in compose bar too as per this issue https://github.com/Expensify/App/issues/11962 removing the prop and adding null instead might help us overcome such scenarios.
Solution:
ListFooterComponent={null}
https://github.com/Expensify/App/blob/245ea00985ead662c3c07a93b1a69651678cee97/src/pages/home/report/ReportActionsList.js#L190
Triggered auto assignment to @Julesssss (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.
@kavimuru I feel like your repro steps were a test to see how quickly I could do them (and... I likely failed) The expected behavior is that chats load once they show in LHN, right? I'm assuming we do that and this is a bug, dishing to a engineer quick for bonus 👀. I can confirm the issue is happening, @Julesssss you can watch the quick vid to see the actual behavior.
I'm assuming we do that and this is a bug, dishing to a engineer quick for bonus
The report data is received when the connection resumes (including the lastMessageText), but the reportAction data is not, which blocks us from viewing the chat. Perhaps this is a bug, but it's also possible we never implemented this logic.
report data

reportAction data

@Julesssss , I would think, with our goal being offline-first, that we'd want to load all report data when we can, vs waiting for an action to be taken. Do you agree?
If so.. I imagine this might be a much larger undertaking. Do you remember who's been working on offline details lately?
Yeah, though we should be careful to retrieve only a partial set of comments (like we do elsewhere with pagination). In this case, I think we should:
-
Start sending a single reportAction comment in the same onyxUpdate data. This ensures that when tapping into a chat, the bold message is shown.
-
Go further, and investigate how we might send additional comments to back-fill the report.
1 seems like a perfectly reasonable solution for now, and as you said 2 is a much larger task that will require discussion
ooooh, so... for this issue we can just have the deliverable be #1 and that'll be finite-enough for someone to fix/update this? If so, that's great. Now, to find someone internally to work on ;)
Yeah, I think that's best. Though, I wonder if this simply needs to be in the optimistic onyx data? If so it doesn't need to be internal.
@mallenexpensify I'll stay assigned for the moment as it might be a simple fix. Will look into this tomorrow
Okay, no that won't solve the problem for other clients. I think the onyxUpdate data in AddComment needs to include the reportAction also. This ensures that anyone who can see the new message can read it. Even if the other comments aren't available.
@mallenexpensify & @kavimuru can you try reproducing this again please? I looked into the code today and this does appear to be implemented correctly. When testing on dev, I could open the chat received while offline 😕
The screenshots are from iOS, but the same thing happened on web.

I'm able to reproduce the bug on Desktop v1.2.21-4 @kavimuru , wanna test web?
@Julesssss @mallenexpensify I am still able to reproduce in Web / Chrome
https://user-images.githubusercontent.com/43996225/198717539-009a1687-0e4f-4378-85f1-cc0fe575b4bd.mp4
Odd, there must be some other step/config that makes this unreliably reproducible.
Keeping assigned until I can retest this again.
Setting this to Daily as per the new process for all bugs.
To help drive this forward I just bumped the original thread where this was reported. cc @grgia Slack thread here
@Julesssss, @mallenexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!
Kickin' the can
Triggered auto assignment to @sophiepintoraetz (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.
Reassigning as I'm heading OOO for a month
@Julesssss - am I correct in that we're waiting on steps to reliably produce the error in order to solicit proposals?
@kavimuru would you mind retesting and determining whether it's occurring on all accounts or just under specific circumstances? As we're not able to reproduce. Thanks
@Julesssss Now in step 6 Enable the internet connection on Device A message appears in normal format then after a second it becomes bold. Bug is not reproducible.
https://user-images.githubusercontent.com/43996225/201477243-46fb2327-0bba-40a3-840e-1d9852a9f97a.mp4
Thank you. Let's close this out. At best it was unreliably reproducible on some devices. If and when it is reliably reproducible we can investigate further.