apps-android-commons
apps-android-commons copied to clipboard
commons-app
Enqueue failed uploads, rather than uploading them simultaneously with the ongoing upload
What is the user problem or growth opportunity you want to see solved?
No response
How do you know that this problem exists today? Why is this important?
Failed uploads are automatically retried as soon as the user returns to the app. They are uploaded simultaneously with the ongoing upload. Enqueuing them gracefully will work more efficiently even when the internet speed is slow.
Who will benefit from it?
No response
Anything else you would like to add?
No response
I experienced this too. Whenever I close and open the app, the failed upload automatically started uploading again. @RitikaPahwa4444 But I thought it was a user-friendly feature.
I'm so sorry for missing out on the context. This issue happens when, let's say, an upload fails after the user turns the screen off, and the app starts uploading the next contribution. Now when the user returns to the app, the failed contribution starts uploading again, even while another upload is in progress.
I tried to reproduce this issue, but the upload doesn't fail when I close the app and remove it from recent apps. Even on switching the screen off, the upload continues, and the image was successfully uploaded, though this couldn't be recorded as the recording was cut as soon as I turned the screen off. Am I missing something here?
@ShashwatKedia If I were to guess, I'd say that the "upload fails after the user turns the screen off" is likely caused by aggressive power saving on users device. The trend in recent phones is even more on stopping apps from running when screen is off, see e.g. https://dontkillmyapp.com/
So probably if you enable your power saving settings more aggressive, it increases the chances of such malfunctions. Also, phone vendor can make a big difference.
But if you need a method of reproducing network errors and seeing how app behaves, you can do that by turning your wifi/data while transfer is running, or (if you want to test while screen is off), rebooting/power-cycling your wifi router.
@ShashwatKedia If I were to guess, I'd say that the "upload fails after the user turns the screen off" is likely caused by aggressive power saving on users device. The trend in recent phones is even more on stopping apps from running when screen is off, see e.g. https://dontkillmyapp.com/
So probably if you enable your power saving settings more aggressive, it increases the chances of such malfunctions. Also, phone vendor can make a big difference.
But if you need a method of reproducing network errors and seeing how app behaves, you can do that by turning your wifi/data while transfer is running, or (if you want to test while screen is off), rebooting/power-cycling your wifi router.
Thanks @mnalis for clarifying this, I was long wondering why I couldn't reproduce this :) I'll try using the power saving mode, as I already tried turning off wifi/data and I did witness an erratic behaviour.
@RitikaPahwa4444 I have a doubt about the ideal flow. When an image Fails, and we close the app and reopen it, then the Failed images get the tag Queued (and would get uploaded when their turn comes). But, if we stay in the app, then the Failed images don't start uploading, even if there is no other image currently being uploaded (or others have finished and only the failed only is left). I felt that queuing the failed images when the user closes the app and reopens it is a good thing, but the flow when the user stays in the app is a bit confusing. I think that the ideal flow (when the user stays in the app) should be that the Failed images would have the Failed tag, until there is no other image left to be uploaded. If no other image is left, then the Failed images will start uploading in a queue. Also, if the retry icon is clicked, then the image can be added to the upload queue, with a Queued tag
But, if we stay in the app, then the Failed images don't start uploading, even if there is no other image currently being uploaded (or others have finished and only the failed only is left).
Could you please share a screencast? The app does check if any uploads failed before ending the process, and so far, I've not faced this issue. This issue is about those failed uploads getting simultaneously uploaded with the ongoing uploads (which should ideally wait until they get uploaded and appear as Queued). However, if you mean "stuck" when you say failed, then they are not tracked by the database and start again only on reopening the app.
Could you please share a screencast?
Sure, here's the link to one.
The app does check if any uploads failed before ending the process, and so far, I've not faced this issue. This issue is about those failed uploads getting simultaneously uploaded with the ongoing uploads (which should ideally wait until they get uploaded and appear as Queued). However, if you mean "stuck" when you say failed, then they are not tracked by the database and start again only on reopening the app.
Um, the only way I could make an upload fail was by turning off my mobile data/wifi, does that cause the upload to be "stuck"? Also, by what factors are we saying that those failed uploads are getting simultaneously uploaded with the ongoing uploads, is it because of the not-started progress bar animation, or their past progress is shown (that is how much of the upload was complete before failing is shown)?
Sorry, was facing some issues while accessing from the Gmail app😅 I've a few questions and observations:
- How long do those queued contributions remain queued? I expect them to get uploaded, this issue is a bit different.
- Turning the wifi off will make all the uploads fail. Are you able to reproduce partial failures?
- Uploads do not get stuck when we turn the wifi off. I just asked because the other case, i.e. failed uploads, is already handled by the app.
- Two or more progress bars move when I say they're getting uploaded simultaneously. This is the usual progress update, not the not-started progress animation you're referring to.
- How long do those queued contributions remain queued? I expect them to get uploaded, this issue is a bit different.
Um, I think you are referring to "How long those Failed contributions remain Failed? " because, mostly, the Queued uploads start uploading when their turn comes. The Failed contributions (the ones in the last part of the recording) do not start until either the retry button is pressed or the app is closed and reopened.
- Turning the wifi off will make all the uploads fail. Are you able to reproduce partial failures?
- Uploads do not get stuck when we turn the wifi off. I just asked because the other case, i.e. failed uploads, is already handled by the app.
Yes, I can reproduce this. You are right, when I turn off the mobile data, then the uploads get Failed, and not stuck.
- Two or more progress bars move when I say they're getting uploaded simultaneously. This is the usual progress update, not the not-started progress animation you're referring to.
Oh, right. I too have observed that, especially when playing with the pause and resume buttons and sometimes when Queued uploads are started again. But I have seen that only one progress bar moves, and the other only shows a particular progress (which is possibly the amount of progress before it failed). I'll test this more and get back to you
I think you are referring to "How long those Failed contributions remain Failed? " because, mostly, the Queued uploads start uploading when their turn comes.
No, I was referring to the Queued state only.
The Failed contributions (the ones in the last part of the recording) do not start until either the retry button is pressed or the app is closed and reopened.
I find that as the intended behaviour.
Yes, I can reproduce this. You are right, when I turn off the mobile data, then the uploads get Failed, and not stuck.
If you're able to reproduce partial failures, then I think you'll be able to reproduce this issue as well. This issue does not involve playing with pause and resume buttons, there are separate issues for them.
No, I was referring to the Queued state only.
Oh, sorry, my bad. The Queued contributions usually get queued only till there is a upload in progress, otherwise they start their upload.
The Failed contributions (the ones in the last part of the recording) do not start until either the retry button is pressed or the app is closed and reopened.
I find that as the intended behaviour.
If that's the intended behaviour, then it's okay. I thought that the app intended to start uploading the Failed items if no other pending upload was left.
Yes, I can reproduce this. You are right, when I turn off the mobile data, then the uploads get Failed, and not stuck.
If you're able to reproduce partial failures, then I think you'll be able to reproduce this issue as well. This issue does not involve playing with pause and resume buttons, there are separate issues for them.
Right, I understood what you are referring to here. Please correct me if I am wrong, the issue here is what happened from 00:21 to 00:25 in the shared recording, right (that is the 2 images have a progress bar simultaneously)?
@RitikaPahwa4444 I tried reproducing this issue and I did get a state where two uploads were Simultaneously showing the progress indicator ( Not "In Progress" but actual progress bar) but at the same time I also added some logs and tried to monitor the the actual behavior of UploadWorker and Noticed that even though two uploads are "shown" to be simultaneously uploading at the same time there were no logs for processing two uploads at the same time, at one time only one upload was getting processing in that dispatcher. I also waited for the upload to complete (when two of them were showing simultaneously uploading indicators) and only one moved and eventually got uploaded. From this , I believe that the uploads are getting enqueued and what we are seeing is due to inconsistency somewhere with updating the UI.
https://github.com/commons-app/apps-android-commons/assets/126143257/72ad7413-89d6-48b1-97b0-58459f413f23
or am I missing something here?
