The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. A Service Worker can be terminated and cannot hold a page PeerConnection or user-selected file indefinitely. Sync fits short idempotent reconstructable requests.
Offline UX distinguishes locally available, pending sync, and server-confirmed states. Cache versions, command queues, and conflict resolution belong together or reconnecting amplifies collisions between old actions and new facts.
Make the implementation decisions explicit
Turn the important choices into durable contracts: validate inputs, assign state ownership, define cleanup, and specify fallback for older peers. Later optimization must not change those semantics.
- Queue only small events and analytics batches with idempotency, retry caps, and expiry; persist large-file resume metadata and reauthorize in foreground.
- Bound every input by size, count, and time, returning a stable actionable error code when a budget is exceeded.
- Retries need an idempotency key, backoff, and deadline; after the deadline create a new task instead of reviving old callbacks.
The delivery standard for Background Sync Cannot Promise a Large File Will Finish is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
Failure paths that are easy to miss
Boundaries turn hidden assumptions into incidents. Weak networks, refresh, concurrency, and capacity need combined coverage because retries can hide each one in isolation.
- Storing whole files for background sync exhausts quota, while promising safe page closure on unsupported browsers destroys trust.
- Fixing only the UI leaves queues, locks, or expired credentials for the next operation to inherit and fail again.
- Without backpressure or quota, a slow consumer raises memory, queue depth, and tail latency until unrelated users are affected.
How to verify it before release
Write the expected state trace before injecting faults. At every phase, reconcile user-visible outcome, both protocol endpoints, persistent records, and resource counts to prove the loop.
- Test unsupported, denied, worker termination, days offline, and permanent 4xx; queues converge and large-file copy makes no false promise.
- Drive the state machine with reordered, duplicate, and delayed messages, proving stale versions are ignored and explicit stop survives recovery.
- Cover direct, relayed, weak-network, background-tab, and mobile paths; do not rely on averages or one successful screenshot.
The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.