Auto-upload: HTTP 423 Locked during Auto Upload; concurrent workers observed #17671

⚠️ Before posting ⚠️

• This is a bug, not a question or an enhancement.
• I've searched for similar issues and didn't find a duplicate.
• I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
• I agree to follow Nextcloud's Code of Conduct.

Steps to reproduce

1. Use the official Nextcloud Android 35.0.0 app with auto-upload enabled for the local camera folder.
2. Configure auto-upload for photos and videos from the local camera directory.
3. Take multiple photos in quick succession, especially Motion Photos (MVIMG_*.jpg).
4. Do not manually start the upload; let background auto-upload process the files.
5. Observe the Android notifications and the reverse-proxy/WebDAV access log.
6. In the affected case, the same new file is checked multiple times, followed by HTTP 423 Locked responses to the WebDAV PUT.
7. The same file may later upload successfully without any server-side intervention.

The problem was reproducible with the official 35.0.0 app on more than one user account on the same Nextcloud server.

After installing the special auto-upload debug APK provided in #16550 as an in-place update, I repeated the same stress test several times and could no longer reproduce the HTTP 423 responses or the visible upload-failed notifications.

Expected behaviour

Each newly created camera file should be processed and uploaded normally.

A successful upload sequence should look like:

HEAD <file> -> 404
PUT <file> -> 201 Created
PROPFIND <file> -> 207

Repeated processing or checks of the same auto-upload item should not result in an HTTP 423 Locked failure that triggers an "Upload failed" notification.

The Android app should not display "Upload failed" notifications when the same file can be uploaded successfully shortly afterwards without any server-side intervention.

Actual behaviour

With the official Android 35.0.0 app, newly created camera files sometimes fail with HTTP 423 Locked.

A sanitized example from an affected user looks like this:

HEAD <remote-folder>/MVIMG_<timestamp>.jpg -> 404
HEAD <remote-folder>/MVIMG_<timestamp>.jpg -> 404
PUT <remote-folder>/MVIMG_<timestamp>.jpg -> 423

A retry may again return:

PUT <remote-folder>/MVIMG_<timestamp>.jpg -> 423

Later, without any server-side intervention, the exact same file succeeds:

PUT <remote-folder>/MVIMG_<timestamp>.jpg -> 201
PROPFIND <remote-folder>/MVIMG_<timestamp>.jpg -> 207

The Android app also shows multiple visible "Upload failed" notifications.

On another account using the same official 35.0.0 app, repeated HEAD/PROPFIND requests for the same files were observed, but no HTTP 423 occurred during the sampled interval.

After installing the special debug APK linked from #16550 on my device, the same workload repeatedly completed successfully with:

HEAD -> 404
PUT -> 201
PROPFIND -> 207

I could no longer reproduce HTTP 423, HTTP 5xx, or the previous upload-failed notifications with the debug APK.

I do not know the exact root cause.

Android version

16

Device brand and model

Xiaomi 24129PN74G

Stock or custom OS?

Stock

Nextcloud android app version

35.0.0 official release Also tested with the special auto-upload debug APK from #16550. The debug APK still identifies itself as Nextcloud-android/35.0.0 in the HTTP User-Agent.

Nextcloud server version

35.0.0

Using a reverse proxy?

Yes

Android logs

Attached: android-debug-DIAGNOSTIC-SANITIZED.txt

This is a privacy-preserving diagnostic extract from the special auto-upload debug APK provided in #16550.

It contains only the relevant auto-upload sequence. Usernames, account names, IP addresses, domains, real paths, real filenames, exact timestamps, IDs and unrelated metadata were removed.

Relative timing, request types, HTTP results, internal Android upload-lock events and final upload status were retained.

android-debug-DIAGNOSTIC-SANITIZED.txt

Server error logs

No corresponding high-severity Nextcloud server error was found for the HTTP 423 responses.

Additional information

This may be related to #16434, but the observed behaviour appears to be different.

In #16434 the original report describes a local camera file remaining locked by the camera application, followed by no automatic retry.

In this case, the reverse-proxy/WebDAV access log shows HTTP 423 Locked responses to the WebDAV PUT after repeated checks of the same new remote file. The same file later succeeds automatically without manual intervention.

After installing the special debug APK from #16550, I can currently no longer reproduce the problem on the previously affected device.

This was tested with multiple users on the same Nextcloud server.

Attached: webdav-access-sanitized-STRICT-v2.txt

Observed behaviour:

• User A, official Android 35.0.0:
  HTTP 423 reproduced. The same file later uploaded successfully.

• User B, official Android 35.0.0:
  repeated HEAD/PROPFIND requests were observed for the same files, but no HTTP 423 occurred during the sampled interval.

• Reporter, official Android 35.0.0:
  HTTP 423 responses and visible "Upload failed" notifications occurred.

• Reporter after installing the special debug APK from Auto-upload: Call for debug help #16550:
  same server, same account, same device and same auto-upload configuration;
  repeated stress tests with many Motion Photos and a video completed without HTTP 423, HTTP 5xx, or upload-failed notifications.

A later access-log check showed additional occurrences with the official Android 35.0.0 app on two different user accounts.

One new image showed:

HEAD -> 404
HEAD -> 404
PUT -> 423
PUT -> 201
PROPFIND -> 207

A Motion Photo on another account showed:

HEAD -> 404
HEAD -> 404
PUT -> 423
HEAD -> 404
PUT -> 423
later PUT -> 201
PROPFIND -> 207

Another Motion Photo on the same account also returned PUT -> 423 and then succeeded shortly afterwards with PUT -> 201.

With the debug APK, representative uploads completed as:

HEAD -> 404
PUT -> 201
PROPFIND -> 207

No HTTP 5xx responses were present in the sampled interval.

I do not know the exact root cause.

webdav-access-sanitized-STRICT-v2.txt