fix(libsync): add NEXTCLOUD_BULK_UPLOAD env override to force-disable bulk upload#10300
Open
mosandlt wants to merge 2 commits into
Open
fix(libsync): add NEXTCLOUD_BULK_UPLOAD env override to force-disable bulk upload#10300mosandlt wants to merge 2 commits into
mosandlt wants to merge 2 commits into
Conversation
mosandlt
requested review from
camilasan,
i2h3,
mgallien and
nilsding
as code owners
July 4, 2026 18:05
mosandlt
force-pushed
the
fix/bulkupload-env-override
branch
from
July 4, 2026 19:00
72ea360 to
a061b60
Compare
Collaborator
|
@mosandlt gentle reminder |
mosandlt
added a commit
to mosandlt/desktop
that referenced
this pull request
Jul 16, 2026
Per review feedback from @mgallien on PR nextcloud#10300 - new env vars should use the NEXTCLOUD_ prefix, not the legacy OWNCLOUD_ one (kept only for the pre-existing OWNCLOUD_CHUNKING_NG override). Signed-off-by: mosandlt <10558666+mosandlt@users.noreply.github.com> Assisted-by: ClaudeCode:claude-sonnet-5
Contributor
Author
|
Renamed to |
nilsding
changed the title
nilsding
approved these changes
Jul 16, 2026
…bulk upload Mirrors the existing OWNCLOUD_CHUNKING_NG override pattern in the same file. Bulk upload (POST .../dav/bulk) is enabled automatically whenever the server advertises the dav.bulkupload capability, with no client-side way to opt out if that endpoint is broken or blocked somewhere in the network path (reverse proxy, WAF, etc). Observed against a self-hosted Nextcloud instance where every single bulk-upload POST failed immediately with UnknownNetworkError, while regular per-file uploads succeeded without issue. Because the failure is deterministic and the client re-attempts bulk upload from scratch on every sync invocation (the in-memory per-file blacklist does not survive across the max-sync-retries restarts, let alone separate nextcloudcmd invocations), affected files never converge and the sync stays permanently red for that server. Setting OWNCLOUD_BULK_UPLOAD=0 lets an operator route around a broken bulk endpoint without needing a custom build, matching the escape hatch already available for chunking via OWNCLOUD_CHUNKING_NG. Signed-off-by: mosandlt <10558666+mosandlt@users.noreply.github.com>
Per review feedback from @mgallien on PR nextcloud#10300 - new env vars should use the NEXTCLOUD_ prefix, not the legacy OWNCLOUD_ one (kept only for the pre-existing OWNCLOUD_CHUNKING_NG override). Signed-off-by: mosandlt <10558666+mosandlt@users.noreply.github.com> Assisted-by: ClaudeCode:claude-sonnet-5
nilsding
force-pushed
the
fix/bulkupload-env-override
branch
from
July 16, 2026 09:20
24f1788 to
baf6cbc
Compare
Contributor
|
Artifact containing the AppImage: nextcloud-appimage-pr-10300.zip Digest: To test this change/fix you can download the above artifact file, unzip it, and run it. Please make sure to quit your existing Nextcloud app and backup your data. |
claucambra
approved these changes
Jul 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds an
OWNCLOUD_BULK_UPLOADenvironment variable override toCapabilities::bulkUpload(), mirroring the existingOWNCLOUD_CHUNKING_NGpattern in the same file (src/libsync/capabilities.cpp).Problem
Bulk upload (
POST .../dav/bulk) is enabled automatically whenever the server advertises thedav.bulkuploadcapability, with no client-side way to opt out if that endpoint is broken or blocked somewhere in the network path (reverse proxy, WAF, CDN, etc).Observed against a self-hosted Nextcloud instance where every single bulk-upload POST failed immediately with
UnknownNetworkError, while regular per-file uploads (PropagateUploadFileNG) succeeded without issue. Because the failure is deterministic and the in-memory per-file bulk-upload blacklist does not survive across the--max-sync-retriesinternal restarts (let alone separatenextcloudcmdinvocations from a cron/systemd timer), affected files never converge — the sync stays permanently red for every file it decides to bulk-upload, run after run, with no recovery path short of patching the client.Fix
OWNCLOUD_BULK_UPLOAD=0forces bulk upload off regardless of server capabilities (falls back to the normal single-file upload path).OWNCLOUD_BULK_UPLOAD=1forces it on. Unset preserves current behavior exactly (server capability decides).Verified locally: rebuilding
nextcloudcmd/libnextcloudsyncwith this change and settingOWNCLOUD_BULK_UPLOAD=0took a sync from a reproducible ~630-file failure batch (100% of that sync's bulk-upload attempts failing withUnknownNetworkError, identical set of files failing across 3 consecutive runs) down to a clean run with zero bulk-related errors, using the regular upload path instead.Testing
dpkg-buildpackagebuild against Debian 12 (bookworm) package3.7.3-1+deb12u2OWNCLOUD_BULK_UPLOAD=0/=1/ unset all behave as expected against a real serverCapabilities::bulkUpload(); behavior for the unset case is unchanged (same expression as before, now reached only after the two new early-return checks)