TUS uploads can get permanently stuck after failed resume; stale uploadinfo is not reset since 3.0

[zerox80]

Since 3.0, large Windows batch uploads (~20GB, many files) become unreliable/stuck. Before 3.0 this worked.

Suspected regression:

• Enable http2 support by default #333 enabled HTTP/2 by default.
• Account starts with _http2Supported=true.
• Folder::loadSyncOptions() returns 20 network jobs for HTTP/2.
• OwncloudPropagator::maximumActiveTransferJob() now uses std::max(3, ceil(parallelJobs/2)), which allows 10 active transfer jobs with HTTP/2 instead of capping at 3.
• Backend advertises TUS creation-with-upload with default 10MB max chunk size.
• Remove unused code from UploadInfo #637 removed repeated upload error reset logic for UploadInfo/TUS.

Repro:

1. Windows client 3.0.
2. OpenCloud backend with default TUS upload protocol.
3. Drop ~20GB/many files into sync folder.
4. Observe upload timeouts/stuck/retries/incomplete uploads.
5. Retest with OPENCLOUD_HTTP2_DISABLED=1 or with transfer concurrency capped at 3.

Expected:
Large batch upload eventually completes.

Actual:
Uploads become unreliable/stuck after 3.0.

@guruz @dragotin

[zerox80]

The issue is not only that uploads fail; after failure the client appears to get stuck permanently. It does not retry from a clean state.

Suspected root cause:

• TUS upload info is persisted in the sync journal.
• On the next sync, PropagateUploadFileTUS::doStartUpload() reuses the persisted UploadInfo URL and starts with a HEAD request.
• If that persisted TUS location is stale/broken, commonErrorHandling() aborts the upload.
• The failed UploadInfo is not cleared in that error path.
• PR Remove unused code from UploadInfo #637 removed checkResettingErrors() and UploadInfo::_errorCount, so repeated failures no longer reset the saved upload state.
• PR Don't persist invalid upload info #638 only avoids persisting invalid upload info without a location, but does not handle stale/broken locations that were already persisted.

[guruz]

If that persisted TUS location is stale/broken, commonErrorHandling() aborts the upload.

You mean server side?

Do you have any more info which error is shown in client?

[guruz]

Retest with OPENCLOUD_HTTP2_DISABLED=1 or with transfer concurrency capped at 3.

Are you saying this leads it to be stale on server side or?

Would this also mean one needs files with multiple chunks to get to reproduce this?