Upload does not progress, image not uploaded (linked to campaigns merge?)

[nicolas-raoul]

Steps to reproduce:

1. Use latest master or any commit since 6588a6f
2. Tap + and the stock gallery button
3. Choose a picture, fill metadata, choose license
4. Push button to start upload
5. As usual, a grey image placeholder appears at the top of Contributions, with a progress bar below
6. Problem: No progress even after waiting for minutes

Commit 67f5b6c does not have this problem, so it seems to be caused by campaigns code?

[misaochan]

Hi @nicolas-raoul , could we get logs for this please?

[misaochan]

Edit: I managed to reproduce this, all of my regular uploads (Contributions > Gallery, not via Nearby) do this in the WLM branch. Unfortunately I did not test regular uploads prior to merging, did not think that they would break. :/

@madhurgupta10 could you please give this bug highest priority now, above any other tasks? This is an absolute blocker for release.

[ashishkumar468]

Hi @nicolas-raoul , I was looking into the logs, and this is the exception I see

2021-08-19 07:46:16.283 31639-31969/fr.free.nrw.commons.beta E/UploadWorker: java.io.FileNotFoundException: No content provider: /data/user/0/fr.free.nrw.commons.beta/cache/CommonsContributions/560c0cab-d1b0-4195-8943-f092b99369045924880408944100467.jpg
        at android.content.ContentResolver.openTypedAssetFileDescriptor(ContentResolver.java:1969)
        at android.content.ContentResolver.openAssetFileDescriptor(ContentResolver.java:1798)
        at android.content.ContentResolver.openInputStream(ContentResolver.java:1475)
        at fr.free.nrw.commons.upload.worker.UploadWorker.saveIntoUploadedStatus(UploadWorker.kt:441)
        at fr.free.nrw.commons.upload.worker.UploadWorker.saveCompletedContribution(UploadWorker.kt:433)
        at fr.free.nrw.commons.upload.worker.UploadWorker.uploadContribution(UploadWorker.kt:314)
        at fr.free.nrw.commons.upload.worker.UploadWorker$doWork$2$invokeSuspend$$inlined$map$1$2.emit(Collect.kt:146)
        at kotlinx.coroutines.flow.FlowKt__BuildersKt$asFlow$$inlined$unsafeFlow$3.collect(SafeCollector.common.kt:115)
        at fr.free.nrw.commons.upload.worker.UploadWorker$doWork$2$invokeSuspend$$inlined$map$1.collect(SafeCollector.common.kt:114)
        at kotlinx.coroutines.flow.FlowKt__CollectKt.collect(Collect.kt:30)
        at kotlinx.coroutines.flow.FlowKt.collect(Unknown Source:1)
        at fr.free.nrw.commons.upload.worker.UploadWorker$doWork$2.invokeSuspend(UploadWorker.kt:214)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:738)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)
2021-08-19 07:46:16.284 31639-31969/fr.free.nrw.commons.beta E/UploadWorker: Upload from stash failed for contribution : test up 131.jpg

Can you please help me understand what changes have we made to save upload status in UploadStatusDao?

[nicolas-raoul]

The problem starting occurring on the commit before the custom selector was merged, so I believe it is not linked to UploadStatusDao.
Anyway @4D17Y4 would you have an idea?

[ashishkumar468]

Yes, there are other errors as well, I have fixed those via this #4567. Upload succeeds now, but the notification shows it fails and the attached logs are the reason
Also, the DB migration is not done, I have increased the version as well in my PR

[nicolas-raoul]

Understood! Here is the context:

The custom selector shows differently pictures that have been uploaded already.
To help with that, we store upload status (uploaded or not) in database.
After each successful upload, we modify the picture's row (if there was one) in the database.

[4D17Y4]

Hey @ashishkumar0207,
I tested ur branch with 2 uploads and the upload seems to succeed with a success notification being displayed.
I see the error can be caused by uploadedStatusDao when the cached file gets deleted.
Can u provide the steps to produce the exception, would help me find the bug.

[ashishkumar468]

Hi @4D17Y4 , it happened to me on a normal upload.

[4D17Y4]

For the changes from Custom Selector.

The uploadedStatusDao as @nicolas-raoul mentioned stores the uploaded status of the images.
Now as the image location/URI of the media can change, the primary key in the database table is the SHA1 of the image. As soon as the upload succeeds we calculate the image sha1 at line 441 and modified image sha1 (EXIF data changed) at line 442 of the upload worker and insert it into the table.

[4D17Y4]

Hi @4D17Y4 , it happened to me on a normal upload.

Can I know what android version you are using?
The error says no content provider which could be due to the Uri format.
I have tested this on android 10.

[ashishkumar468]

Its android 10, Pixel 3A

[misaochan]

Thanks for working on this! I do want to clarify that I was testing on 3.1-release branch, which contains WLM integration but not custom picture selector.

[nicolas-raoul]

I tested #4567 today, uploading about 20 pictures using various methods (single, multiple, stock picker, custom picker, nearby). I saw many <myfile> uploaded! notifications and did not notice any erroneous failure notification.
Among these 20, I got two failures on single uploads (that happens often, maybe due to my slow Internet):

• One retry worked and resulted in a "already uploaded" icon being visible in the custom picker.
• One retry worked but did not result in a "already uploaded" icon being visible in the custom picker, meaning the custom picker lets me pick that picture, despite it being on Commons already. Not sure why, but that's not a blocker issue.

My conclusion: #4567 is a great improvement :-)

[ashishkumar468]

IMO, if things are fine, let's get this merged to master, and then cherry-pick the fixes to 3.1-release, that way master would also be rid of the bug. If at all any improvisation is needed around the custom-selector logic, those can go on master.