fix(auto-upload): skip check

[alperozturk96]

Issue

Worker might mark entity as handled but this is not enough worker may get killed and never reached to the actual upload thus oc upload records should be checked as well.

Fixes

#15573

[github-actions]

APK file: https://github.com/nextcloud/android/actions/runs/30632262721/artifacts/8794164956
To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud app.
(please click on link to get QR code displayed)

[github-actions]

master-IT test failed: https://www.kaminsky.me/nc-dev/android-integrationTests/17401-IT-master-13-46

[DricomDragon]

I installed the QA app, logged in, gave permission to manage all files, (disabled auto-upload on stock APK), configured the auto upload of video and photograph in camera (after having renamed the previous folder to Camera1 to prevent mass upload), Wi-Fi is enabled, I plugged my phone, took a photograph and video : no effect.

Unplug from charger, plug to my computer, capture logs, go to uploads, pause / play, go to manage auto uploads : I can see my picture and video in the auto-upload configurator, but nothing automatically uploaded yet. Maybe unrelated to your patch, though.

Here are the logs :
qa-logs-redacted.txt

I will use this QA version from now on, I will notice you about uploads or skips when noticed.

Thanks for your amazing work, have a good day !

[github-actions]

APK file: https://github.com/nextcloud/android/actions/runs/31084696925/artifacts/8961049995
To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud app.
(please click on link to get QR code displayed)

[robdupas-svg]

Setup:

• Uninstalled F-Droid stable, installed QA build fresh
• No pre-existing Camera rule (no photos yet taken); a default, disabled ScreenRecorder rule was auto-created from recordings made the previous day
• Created a manual Camera rule pointing at DCIM/Camera

Test sequence and results:

1. Un-installed F-Droid app
2. Installed the QA version
   • Once opened, I was prompted to
   • Allow notifications
   • Allow access to all files
3. Started to create the Camera rule
   • recommendation to turn on background autostart (did this)
   • No default Camera rule (I had taken no photos yet)
   • Created it
   • Took longer than usual to discover the folders on my server
   • A default ScreenRecorder rule was already setup
   • I have taken some recordings yesterday
   • I left it disabled
4. Closed Nextcloud
5. Took a photo
   • Waited 60 seconds and it still did not automatically upload to the server
6. Opened Nextcloud app
   • Nothing automatically uploaded
   • 2 Camera rules now exist.
   • The one I created shows 5 photos (4 of which I deleted yesterday)
   • The Nextcloud generated Camera rule
7. Deleted the manually created rule
8. Configured and enabled the Nextcloud Camera rule
   • The photo uploaded automatically after I did this
9. Closed Nextcloud
10. Took another photo
11. Waited another minute
12. Nothing uploaded
13. Checked the app state
    • Apps\Manage apps\Nextcloud
    • Seems to be running as “Force stop” is not greyed out
14. Opened Nextcloud
    • Both photos I took appear as icons in the rule
    • Toggling upload had no effect
15. Created a new Camera rule
    • Photo uploaded automatically
16. Closed Nextcloud
17. Took another photo with both rules active
18. Waited another minute
19. No automatic upload so I opened Nextcloud
    • The custom rule still shows several photos I deleted yesterday + newly created photos
20. Still no automatic upload so I deleted the custom rule
21. No upload
22. Created a custom new rule again
23. No upload … nothing will upload again

Conclusion:
It appears the app is running in the background (13) above. The last time I tried the test, the Nextcloud camera rule was already created when I first open Auto upload. I can’t remember if I had photos on the phone already. However, it does appear the act of creating a custom folder (either before or after the Nextcloud rule) triggers the upload. This appears to only work once though as my uploads are now frozen.

[github-actions]

APK file: https://github.com/nextcloud/android/actions/runs/31570429137/artifacts/9131278591
To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud app.
(please click on link to get QR code displayed)

[DricomDragon]

✔️ Hello, I did not notice any missing photo since I installed the first QA apk of this thread. Look promising, thanks for your work ! Looking ahead to become stable. I just installed the last QA apk from this thread, and keep using on a daily basis to keep pictures in sync, I would report any sync issue.

[github-actions]

blue-Light-Screenshot test failed, but no output was generated. Maybe a preliminary stage failed.

[github-actions]

APK file: https://github.com/nextcloud/android/actions/runs/33478479014/artifacts/9789254211
To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud app.
(please click on link to get QR code displayed)

[github-actions]

Codacy

SpotBugs

Category	Base	New
Bad practice	32	32
Correctness	59	59
Dodgy code	207	207
Experimental	1	1
Malicious code vulnerability	2	2
Multithreaded correctness	25	25
Performance	39	39
Security	19	19
Total	384	384

[JDubbedN]

@alperozturk96 I spent several hours testing the latest QA APK from this PR and wanted to report the results. Overall, the fix for interrupted/unfinished uploads appears to be working very well, but I also found a reproducible post-reboot auto-upload timing issue that may be separate from this PR.

Test setup

• Latest QA APK from the September 1 artifact on this PR
• Production Nextcloud Android app auto-upload disabled during testing
• QA custom auto-upload folder:
  • Local: /storage/emulated/0/DCIM/Nextcloud-QA-Test
  • Remote: /Nextcloud-QA-Test/
• Upload existing files: enabled
• Wi-Fi only: enabled
• Charging only: disabled
• Android battery setting for Nextcloud QA: Unrestricted
• Background data: Allowed
• Nextcloud QA is not in Android Sleeping Apps or Deep Sleeping Apps
• Server: Nextcloud 34.0.3

Normal background auto-upload

PASS

A fresh photo copied into the watched folder was detected and uploaded in approximately 5–10 seconds without manually opening the QA app.

I also tested with the phone screen off. Multiple photos successfully uploaded while the device was locked and the QA app was not in the foreground.

After leaving the phone idle for approximately 15 minutes, another photo also uploaded successfully with the screen off.

Upload timing was somewhat variable. One photo took several minutes, but subsequent photos uploaded normally while the screen remained off.

Interrupted upload — network loss

PASS

I copied a 419 MB video:

20260827_173150.mp4

I waited until the upload had definitely started, then enabled Airplane Mode to interrupt the transfer.

I also accidentally dismissed/swiped away the active Nextcloud upload notification while offline.

After approximately 30 seconds I disabled Airplane Mode, did not open the QA app, and waited.

Nextcloud later generated a new upload notification automatically and the entire 419 MB video successfully appeared in the remote folder.

The QA logs confirm the chunked upload eventually completed with:

FinalStatus: UPLOAD_SUCCEEDED

So the unfinished-upload/requeue behavior addressed by this PR appears to work correctly in this test.

Interrupted upload — full phone reboot

PASS

I then performed a stronger interruption test using a 400+ MB video:

20260805_175946.mp4

I copied the video, waited until Nextcloud displayed the active upload notification, and rebooted the phone while the large video was definitely still uploading.

After reboot:

• I unlocked the phone
• I did not open the Nextcloud QA app
• I did not manually retry or recopy the video

The upload recovered automatically and 20260805_175946.mp4 eventually appeared completely in the remote folder.

This indicates unfinished-upload recovery also survives a full Android/device reboot.

I performed an earlier similar test with a smaller ~100 MB video (20260819_110857.mp4) which also appeared after reboot, although that test was somewhat ambiguous because the video might possibly have finished before the reboot interrupted it. The 400+ MB test removed that ambiguity.

Reproducible issue: new files shortly after reboot can remain pending

I found a separate behavior and reproduced it twice.

Controlled reproduction:

1. Reboot phone.
2. Do not open Nextcloud QA.
3. Copy 20260904_122552.jpg into the enabled auto-upload folder.
4. Leave the screen off for approximately 5 minutes.
5. File does not upload.
6. Wake the phone while leaving it locked for 30 seconds.
7. File still does not upload.
8. Open the Nextcloud QA app and leave it open for approximately one minute without changing any settings.
9. File still does not upload.
10. Copy another image, 20260903_210922.jpg, into the same watched folder.
11. Approximately 20 seconds later auto-upload activates.
12. Both 20260903_210922.jpg and the previously pending 20260904_122552.jpg upload successfully.

I reproduced essentially the same behavior in an earlier reboot test as well: the first post-reboot photo remained pending until another new file was added, at which point both files uploaded.

The QA logs appear to match the observed behavior very closely.

When I opened the app while the first file was still pending, the log showed:

AutoUpload; skipped since started before scan interval and nothing todo

Later, when the second file was added, the content observer logged:

ContentObserverWork; auto upload triggered successfully for 2 file(s).

The logs then show the previously pending 20260904_122552.jpg beginning its upload and completing successfully.

This makes it look like the first file is not permanently marked as handled/skipped. Instead, shortly after reboot it can fail to be discovered/processed until a later MediaStore/content-observer event causes another scan.

Longer post-reboot test

There is another important detail: this does not appear to remain broken indefinitely after reboot.

After leaving the phone running for roughly an hour without continuing the test, I copied:

20260811_170102.jpg

It uploaded successfully without opening the QA app.

Interestingly, that upload was completely silent — there was no Android Nextcloud upload notification at all. I only confirmed it by checking the remote Nextcloud folder.

This suggests there may be a post-boot initialization/scheduling race or delay rather than the content observer remaining permanently inactive.

Notification behavior

I also found that Android upload notifications are not a reliable indicator of whether auto-upload is actually working.

Some successful background/reboot-recovery uploads produced notifications, while others completed completely silently. For testing I therefore verified actual file arrival on the Nextcloud server rather than relying only on Android notifications.

Summary

From my testing:

• Normal background auto-upload: PASS
• Screen-off auto-upload: PASS
• Interrupted upload via network loss: PASS
• Automatic retry/requeue without opening app: PASS
• Interrupted 400+ MB upload across full phone reboot: PASS
• File added shortly after reboot: reproducible delay/failure to discover
• Previously pending post-reboot file is recovered when a later file event triggers another scan: PASS
• Auto-upload eventually becomes functional later after reboot: observed
• Android upload notifications: inconsistent / sometimes completely silent

Overall, PR #17401 appears to successfully solve the interrupted/unfinished-upload case I was specifically trying to reproduce. The remaining problem seems more related to the post-reboot content observer / auto-upload worker initialization or scan scheduling.

I also captured QA logs from these tests. I noticed the exported log contains the account app password in plaintext, so I am intentionally not attaching the raw log publicly. I can provide a redacted version if useful.

Thank you for working on this. I hope the detailed reproduction helps.