Pictures are no longer auto-uploaded if folder could not be created the first time
Nobody has claimed this yet.
- Dominant language
- Swift
- Stars
- 2.5k
- Forks
- 1k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 13
Description
Steps to reproduce
- Set autoupload on iOS app to external storage folder.
- Due to a maintenance issue, that folder on the server is temporally non-writable.
- iOS client tries to create a folder for the month (e.g. /externalstorage/Iphone Uploads/2021/10) and fails.
Expected behaviour
The app should give some feedback to the user that the folder could not be created due to an error, and the app should try again the next time it tries to upload a picture into that folder.
Once the external storage is writable again and the folder could be created, try uploading the pictures again.
Actual behaviour
The app tries to upload the pictures to the inexisting folder no matter what, triggering a HTTP 409 error for each file. (See post https://help.nextcloud.com/t/http-error-409-conflict-when-autouploading-from-iphone/125884 for more details)
If the folder is created manually, picture uploading resumes, but pictures that were not uploaded during that period of time won't be uploaded automatically anymore.
Screenshots
Nothing out of the ordinary appears in the app.
Logs
This is what I see on the server when the client tries uploading files to a non-existing folder:
193.123.xx.xx - User [22/Oct/2021:00:12:10 +0000] "PUT /remote.php/webdav/PersonalUser/Iphone%20Upload/2021/10/21-10-01%2007-45-42%207764.png HTTP/1.1" 409 3078 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.0.6"
193.123.xx.xx - User [22/Oct/2021:00:12:10 +0000] "PUT /remote.php/webdav/PersonalUser/Iphone%20Upload/2021/10/21-10-01%2007-47-03%207765.png HTTP/1.1" 409 3070 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.0.6"
193.123.xx.xx- User[22/Oct/2021:00:12:10 +0000] "PUT /remote.php/webdav/PersonalUser/Iphone%20Upload/2021/10/21-10-01%2007-48-11%207766.png HTTP/1.1" 409 3066 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.0.6"
193.123.xx.xx - User [22/Oct/2021:00:18:12 +0000] "PUT /remote.php/webdav/PersonalUser/Iphone%20Upload/2021/10/21-10-01%2007-47-03%207765.png HTTP/1.1" 409 2560 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.0.6"
193.123.xx.xx - User [22/Oct/2021:00:18:12 +0000] "PUT /remote.php/webdav/PersonalUser/Iphone%20Upload/2021/10/21-10-01%2007-45-42%207764.png HTTP/1.1" 409 2560 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.0.6"
193.123.xx.xx - User [22/Oct/2021:00:18:12 +0000] "PUT /remote.php/webdav/PersonalUser/Iphone%20Upload/2021/10/21-10-01%2007-48-11%207766.png HTTP/1.1" 409 2560 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.0.6"
193.123.xx.xx - User [22/Oct/2021:15:35:35 +0000] "PUT /remote.php/webdav/PersonalUser/Iphone%20Upload/2021/10/21-10-01%2007-45-42%207764.png HTTP/1.1" 409 3066 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.0.6"
193.123.xx.xx - User [22/Oct/2021:15:35:35 +0000] "PUT /remote.php/webdav/PersonalUser/Iphone%20Upload/2021/10/21-10-01%2007-48-11%207766.png HTTP/1.1" 409 3064 "-" "Mozilla/5.0 (iOS) Nextcloud-iOS/4.0.6"
Reasoning or why should it be changed/implemented?
A user might think that the pictures are being backed up to a server when in fact they are not.
Environment data
iOS version: 15.0
Nextcloud iOS app version: 4.0.5
Server operating system: Debian
Web server: docker version available at https://hub.docker.com/_/nextcloud
Database: mysql 8
PHP version:
Nextcloud version: 22.1.0
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No source files or tests are named. Start by tracing the iOS autoupload flow for monthly folder creation and handling of HTTP 409 responses; verify the failure is surfaced to the user, the folder is retried after it becomes writable, and previously missed pictures are uploaded.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- mobile
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100