# Bug 4019: Offline mode

- Status: closed
- Project: Zero
- Creator: @aboodman
- Assignee: @0xcadams
- Created: 2025-07-17T09:58:57Z
- Modified: 2026-07-11T20:41:14Z
- Reactions: ➕️ ×4 (owenandrews, saibotma, stewartfortier, tienpv222) · 👍️ ×1 (uptonking)
- URL: https://bugs.rocicorp.dev/p/zero/issue/4019

## Description

For beta, Zero will not support offline writes. This has been documented here:

https://zero.rocicorp.dev/docs/offline

We need to implement an "offline mode" that detects when requests stop getting processed for some time (~5 minutes). When in offline mode, all writes to Zero are rejected.

This offline mode should be coupled to Zero's existing `onOnline` event. When `onOnline(false)` happens, the writes should start getting rejected. When `onOnline(true)` happens, writes start getting accepted again.

When entering offline mode, any queued mutations stay queued.

## Comments (4)

### @joodaloop — 2025-08-05T14:37:21Z

Will there be a way to switch keep offline writes through a very explicit setting? I plan to use backwards-compatible mutators in an event sourcing style so offline writes will always be accepted. For semantic conflicts, there will be a UI to fork and replay thanks to the vent sourcing-driven version history.

Related question: Can a running version of an app tell when the zero-cache is using a different schema and gracefully fall back to only reading from local cache + allowing writes? I will present a "refresh to upgrade" message but don't want to have to interrupt a session or prevent app usage if possible.

Reactions: 👍️ ×2 (Stanton-B, saibotma)

### @aboodman — 2025-08-05T22:34:48Z

> Will there be a way to switch keep offline writes through a very explicit setting?

No, not for beta. We want to do this, but there is some work necessary in Zero internals to properly support a few corner cases of offline writes. See: https://zero.rocicorp.dev/docs/offline#-and-a-sync-engine-problem

> I will present a "refresh to upgrade" message but don't want to have to interrupt a session or prevent app usage if possible.

Yes, once above problems with Zero are fixed, your proposed UI would work. Replicache had that and Zero inherits it.

### @mashpie — 2025-08-18T21:06:56Z

Exactly what I was thinking of. With custom mutations as commands (in terms of CQRS) and ES we implement server side conflict resolution anyway. UI depends on use case. “New Doc” is easy to catch and handle offline first while “Change Password” could be declined when offline. My vote for opt-in to enable offline mode globally, per model or even per mutation. Thoughts?

### @joodaloop — 2025-09-09T02:39:55Z

Yeah, I would be implementing "change password" and other synchronous actions through a regular fetch request anyway. Which is why I'd like the ability to keep everything that can function offline available to the user.