# Bug 246605: Offline Writes

- Status: open
- Project: Zero
- Creator: @aboodman
- Created: 2026-02-07T16:59:52Z
- Modified: 2026-03-23T08:02:35Z
- Reactions: 👀 ×2 (Stanton-B, joodaloop) · 👍️ ×1 (danielcompton)
- URL: https://bugs.rocicorp.dev/p/zero/issue/246605

## Description

Zero doesn't currently support offline writes. This bug tracks the known technical blockers.

## Mutation Recovery

When a write happens while `connecting`, it is written to local storage and replayed on next connection – even across app restarts.

However, if that app restart gets a new version of Zero, or a new schema version, Zero creates a new local storage area and the offline write is effectively lost - marooned in the old storage area.

In Replicache, this was solved with a system called "mutation recovery" that rescued these mutations from prior schema/Zero versions. This system needs to be ported to Zero.

## Slow connection with lots of offline writes

When Zero starts, it sends all queued mutations to the server and simultaneously pulls updates from the server. When the server updates are applied, any queued mutations are "rebased" (re-run locally) to resolve conflicts.

If there are many locally queued changes, this process can be arbitrarily slow.

To support long periods offline, Zero should probably have a mode where it first sends all queued mutations, then replays them after the server updates are applied. But this would conflict with the goal to startup and get server updates fast when there aren't many queued mutations, so some work would be needed to balance these two goals.

## Offline Mutations Must Never Be Rejected

When a mutator throws an error on the server, the handleMutateRequest function in `@rocicorp/zero/server` returns the error to the client but marks the mutation processed.

This is a good UX and DX when online because it mirrors the behavior of normal web apps.

When offline, mutations should never be rejected. Otherwise the user could lose arbitrarily large amounts of work. Mutations should be replayed until they can be accepted.

This would require a different implementation of `handleMutateRequest`. Also the developer would have to be very careful to respond to any erroring mutations quickly, as those clients will be unable to save work until the error is resolved. There may be additional product work required to make this work well.

## Mutation should probably be opt-in offline capable on a case-by-case basis

Making the entire app work well fully offline is probably unrealistic for most apps. It feels more likely that people will succeed by making subsets of their apps work offline. Even major apps work this way to day -- you can "like" a post on FB while offline but can't compose or edit.

## Comments (4)

### @G2Jose — 2026-02-22T19:55:36Z

I really wish this feature existed, because it's a hard blocker for my app. I currently use powersync and really like it, but I'd love to try out Zero because of its ability to resolve queries synchronously on the very next frame.

Reactions: ❤️ ×3 (Stanton-B, aboodman, devagrawal09)

### @aboodman — 2026-02-23T17:09:23Z

I understand and appreciate that. Unfortunately, we can’t do everything and have chosen to focus on online for the foreseeable future.

You might want to check out livestore which focuses on offline and synchronous writes.

### @vinayakyadav2709 — 2026-03-23T07:17:24Z

See how others are doing the it? there must be solutions right?

### @vinayakyadav2709 — 2026-03-23T08:02:35Z

so are we implementing this? can you share some resources or theory so I can try implementing some solution