fix(libsync): add OWNCLOUD_BULK_UPLOAD env override to force-disable bulk upload#10300
Open
mosandlt wants to merge 1 commit into
Open
fix(libsync): add OWNCLOUD_BULK_UPLOAD env override to force-disable bulk upload#10300mosandlt wants to merge 1 commit into
mosandlt wants to merge 1 commit into
Conversation
…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 <[email protected]>
72ea360 to
a061b60
Compare
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
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)