iCloud Drive silent upload deadlock caused by stale HTTP/3 session in nsurlsessiond (FB22476701)

Summary

On macOS 26.4.1 (25E253), iCloud Drive file uploads can enter a silent deadlock where every upload attempt fails at the transport layer. No error is surfaced anywhere — not in Finder, not in System Settings, not in the iCloud status panel. The upload queue simply stops.

Other iCloud services (Photos, Mail, App Store) continue to work normally through the same networking infrastructure at the same time.

Root Cause

The issue is a stale HTTP/3 (QUIC) session cached in the user-level nsurlsessiond process's BackgroundConnectionPool.

The deadlock cycle:

1. cloudd requests an upload to the GCS storage endpoint
2. nsurlsessiond provides the cached (broken) HTTP/3 session
3. The TLS handshake succeeds, but the body upload dies mid-transfer (err=T, requestDuration=-1.000, responseHeaderBytes=0)
4. cloudd retries with a new connectionUUID — but nsurlsessiond still routes through the same poisoned QUIC session
5. This repeats indefinitely

Killing cloudd alone does not help — nsurlsessiond retains the poisoned pool. Only killing both the user-level cloudd and nsurlsessiond clears the pool and forces a fresh protocol negotiation.

The Smoking Gun

After killing both daemons, the system falls back to HTTP/1.1 for the stuck uploads — and they complete instantly:

Same endpoint, same files, same network interface (en5), same power state. The only change was the protocol negotiation after a fresh nsurlsessiond.

Reproduction

Reproduced 3 times on April 11, 2026 using a standardized set of 8 test files (8 bytes to 20 MB) in a non-shared iCloud Drive folder. Each run showed the identical pattern:

• Small files (<100 KB) squeeze through before the QUIC session stalls
• Larger files trigger the deadlock every time
• 5–6 retries with fresh connectionUUIDs, all failing over protocol=h3
• After kill cloudd + nsurlsessiond: immediate flush via protocol=http/1.1

An automated evidence-collection script (collect_h3_deadlock_evidence.sh) captures paired before-kill / after-kill logs. Included in the Feedback report.

Symptom Check (for others hitting this)

/usr/bin/log show --predicate 'process == "cloudd"' --last 5m 2>&1 \
  | grep "putContainer.*err=T.*requestDuration=-1.000.*protocol=h3" | wc -l

Output > 0 = this deadlock. Output = 0 = different issue.

Recovery (one-liner)

kill $(ps -axo user,pid,command | awk -v u="$USER" \
  '($1==u && /CloudKitDaemon.framework.*cloudd/ && !/--system/) \
  || ($1==u && /\/usr\/libexec\/nsurlsessiond/ && !/--privileged/) \
  {print $2}')

Both daemons respawn within 1–2 seconds. Do not use killall nsurlsessiond — it would also kill the privileged system instance.

What was ruled out

• Network connectivity (Photos uploaded 8 MB through the same pool simultaneously)
• iCloud account (metadata operations succeeding, only body uploads failing)
• File type/content (random data, correlation is with size, not type)
• Storage quota (1.65 TB free)
• CFNetworkHTTP3Enabled=false (key is ineffective in 26.4.1)

Suggested fixes (from the Feedback report)

1. CFNetwork: Invalidate the QUIC session after N consecutive requestDuration=-1.000 failures
2. CloudKit/NSURLSession: Expose a pool invalidation API like [NSURLSession invalidatePoolEntryForEndpoint:]
3. cloudd: Self-healing retry — create a fresh NSURLSession after M consecutive deadlock-signature failures
4. Finder: At minimum, surface the stuck state to the user instead of failing silently

Filed as

FB22476701 — includes full reproduction timelines, request/connection UUIDs, sysdiagnose, and a 12-page investigation PDF with architecture diagrams and protocol comparison tables.

If you're experiencing the same issue, please file a duplicate referencing FB22476701 — Apple prioritizes by duplicate count.

System

• MacBook Air, macOS 26.4.1 (25E253)
• iCloud Drive with Desktop & Documents sync
• en0 (WLAN) + en5 (USB-LAN via Studio Display)