[HOLD] No loading animation or preview for persisted attachments

[thienlnam]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Creating a new ticket for: #3867 (comment)

Action Performed:

1. Be offline
2. Select an attachment to be uploaded (preferable larger so it takes more time to upload)
3. Quit the app
4. Open the app again
5. Open the chat where the attachment was uploaded
6. Observe it's not there, and there's no indication something is uploading
7. The attachment only appears after the upload is over

Expected Result:

There should be an indication or preview of the attachment being uploaded

Actual Result:

No preview or loading animation while the attachment was being uploaded

Workaround:

The attachment will still be uploaded, the user will just not know that it's in the process of being uploaded

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number:
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by: @kidroca
Slack conversation:

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @sonialiap (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

[MelvinBot]

Triggered auto assignment to @puneetlath (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[thienlnam]

Sorry for the tags and pings, I'm breaking down #3867 (comment) into separate tickets so they can be investigated and be known as existing bugs. This will still need an upwork job created for it

[thienlnam]

@kidroca Proposal:

I think we should try to cross reference optimistic actions with requests in the network queue
This way when we clean up optimistic actions we keep the ones that still have pending request

We already put optimisticReportActionID on the request so we can distinct it

App/src/libs/actions/Report.js

Lines 1169 to 1175 in 425e718

	API.Report_AddComment({
	reportID,
	file,
	reportComment: commentText,
	clientID: optimisticReportActionID,
	persist: true,
	})

We can make a lib or expose a function that return any pending Report_AddComment actions from network queue or persisted storage
Report.removeOptimisticActions would use that and skip removing optimistic actions that have pending Report_AddComment

[kidroca]

BTW the next design of the network write queue would first persist requests to Onyx
We can assume that as long as the request with optimisticReportActionID is still in Onyx the attachment is still uploading

So for any optimistic action we can make a cross check to Onyx and keep the optimistic action (to represent loading state) if it can be cross referenced to data in Onyx

Note: the new network write queue is yet to be implemented

[thienlnam]

Sounds good, going to put this on hold until that new write queue is completed but will keep this issue up so people are aware of this known bug

[puneetlath]

I'm going to unassign since I'm going on sabbatical soon. Please re-apply the External label when it's off hold to get someone assigned.

[thienlnam]

I know we've added batching but the new write queue doesn't seem to be done yet correct? @kidroca

[kidroca]

Yes, that's correct
I think these are the latest new about the write queue: https://expensify.slack.com/archives/C01GTK53T8Q/p1648658394841419
There's a design doc link, which is not accessible by everybody

I think the write queue changes would be applied somewhere along the way

[thienlnam]

Still holding

[thienlnam]

Going to close this for now until we decide we want to add it in the future