Request Details

I would love to be able to use SpacetimeDB in an app that:

  1. robustly handles disconnection from a server, and then syncs and catches up when it reconnects
  2. propagates updates locally immediately first, and rolls back or corrects if necessary after propagation to the server

This would be similar to what replicache enables.

  1. website-features added the feature-request label Jul 4, 2026
  2. I stumbled up on https://github.com/powersync-community/powersync-convex-todolist-demo which is an experimental way of integrating a Local sqlLite with Convex. Maybe the Power Sync community could also help to Build a spacetimeDB Integration 🤔

  3. I'd like to propose a scope for this that keeps SpacetimeDB out of the "sync engine" business: ship a small set of mechanisms and leave the policy (what an intent means when it lands late) to the developer, who knows their domain.

    Opt-in per reducer. Something like #[reducer(offline)] marks a reducer as safe to apply late. Only those get queued; everything else keeps today's fail-fast behaviour, so existing apps are unaffected.

    The mechanisms:

    1. Idempotent reducer calls. Calls carry a (client_stream, seq) id; the server keeps an applied set per stream and stores results, including errors, so a retry returns the stored outcome instead of running the reducer again. This is the same shape as Async IDC's st_inbound_stream / st_inbound_msg. It's useful on its own: it would let auto-reconnect (#5927) safely resend calls that currently settle with UnknownCallResultError. I'd suggest it as the first step.
    2. Intent context on the reducer context. The client timestamp, the last transaction offset the client had observed, and a replay flag, so a reducer can tell that an intent is stale and apply its own policy (reject, merge, last-write-wins).
    3. Resumable subscriptions. Subscribe from a transaction offset, falling back to a full resend when it's too old, so reconnecting after days doesn't re-download everything.
    4. A persistable client cache and a durable outbox in the SDKs, with hooks such as onApplied / onRefused.

    Left to the developer: conflict semantics, how refusals are surfaced in the UI, what data is kept offline, and platform storage persistence. The docs would need to state the risks of applying intents late plainly.

    Prior art: spacetimedb-predict covers the latency side (in-memory only, with a 10 s timeout); Replicache uses the same split between mutators and server-authoritative rebase.

Reopen this request?

The request will return to its prior live status.

Mark as Duplicate

Pick the request that Offline-first support is a duplicate of. Energy rolls up into that request and GitHub closes the linked issue as a duplicate with a timeline reference to the canonical.

Unmark Duplicate

Restore as an independent request. The linked GitHub issue will be reopened and its duplicate-of relationship cleared. The original timeline entries stay as history; the note below is posted as a follow-up comment.