When syncing — in either direction — a transient rate-limit response ({"error":"Too many requests"}) from the auth server's .well-known/openid-configuration endpoint causes JobQueue::clear() to fire, aborting all pending jobs regardless of type: GETFileJob (downloads), SimpleNetworkJob / POST (uploads), and TUS transfers. Running jobs are critically deleted. The sync engine declares the run complete, so aborted files are never retried and the client shows no error. Quitting and restarting repeatedly eventually works through the backlog, but it takes many cycles.
Reproduced on two different Macs (MBP M1 Max and Mac Mini M4), both running client 3.0.3.2073 against OpenCloud 7.1.0. On the MBP, four consecutive log segments (spanning ~3 minutes of restarts) each show the identical failure: upload jobs aborted by the same rate-limit cascade. The Mini captured the download-side failure cleanly.
Steps to Reproduce
- Create a space with several hundred files across nested directories
- Connect a macOS desktop client (3.0.3.2073) to sync that space, HTTP logging enabled
- Observe discovery + reconciliation complete normally, jobs queued
- A
.well-known/openid-configuration fetch returns {"error":"Too many requests"}
JobQueue::clear() aborts all pending jobs — POST (uploads), GET (downloads), and running jobs- Client shows no error; directories exist but files are missing; subsequent syncs skip already-"synced" items
MBP Upload Failures (4 consecutive restarts, each aborted)
11:53:51 JobQueue::clear → Abort SimpleNetworkJob ×21 (POST uploads) + 12 critical deletions
11:54:33 JobQueue::clear → Abort SimpleNetworkJob ×21 (POST uploads) + 10 critical deletions
11:55:05 JobQueue::clear → Abort SimpleNetworkJob ×22 (POST uploads)
11:55:32 JobQueue::clear → Abort SimpleNetworkJob ×21 (POST uploads) + 3 critical deletions
Mini Download Failure (initial sync)
11:59:08 .well-known → {"error":"Too many requests"} → JobQueue::clear
Abort GETFileJob ×20 + Deleting running job ×5
Result: 88/100s of files synced, directories empty
Environment
- macOS 26.4.1 (Mac Mini) / 25.5.0 (MBP), client 3.0.3.2073
- OpenCloud 7.1.0 behind Caddy, HTTP/2 enabled
- Pocket ID (OIDC) auth at separate auth server
Workaround
Quitting and restarting the client repeatedly eventually works through the sync backlog, as each cycle gets a few more files through before hitting the rate limit again.
Related
When syncing — in either direction — a transient rate-limit response (
{"error":"Too many requests"}) from the auth server's.well-known/openid-configurationendpoint causesJobQueue::clear()to fire, aborting all pending jobs regardless of type:GETFileJob(downloads),SimpleNetworkJob/POST(uploads), and TUS transfers. Running jobs are critically deleted. The sync engine declares the run complete, so aborted files are never retried and the client shows no error. Quitting and restarting repeatedly eventually works through the backlog, but it takes many cycles.Reproduced on two different Macs (MBP M1 Max and Mac Mini M4), both running client 3.0.3.2073 against OpenCloud 7.1.0. On the MBP, four consecutive log segments (spanning ~3 minutes of restarts) each show the identical failure: upload jobs aborted by the same rate-limit cascade. The Mini captured the download-side failure cleanly.
Steps to Reproduce
.well-known/openid-configurationfetch returns{"error":"Too many requests"}JobQueue::clear()aborts all pending jobs —POST(uploads),GET(downloads), and running jobsMBP Upload Failures (4 consecutive restarts, each aborted)
Mini Download Failure (initial sync)
Environment
Workaround
Quitting and restarting the client repeatedly eventually works through the sync backlog, as each cycle gets a few more files through before hitting the rate limit again.
Related