Docs

When things break

Honest answers — what Eidos promises, and what it does not.

Next: Recipes →

Offline

  • neverLose actions land in IndexedDB and wait.
  • Offline reads come from the Service Worker cache when you registered resource(..., { offline: true }).
  • Use header **sim offline** in this playground to practice without killing Wi‑Fi.

Reload / crash mid-flight

  • Queued work survives reload because it lives in IndexedDB, not React state.
  • Actions need a stable name so replay can find the function after boot.
  • Multi-tab: Web Locks coordinate who replays — tabs do not steal each other’s live work.

Uncertain response

  • Network died after the server may have succeeded → Eidos may retry.
  • Same idempotencyKey is reused so your API can return the original result.
  • This is **at-least-once delivery**, not magical exactly-once business logic.

Server duties checklist

  • Accept and store idempotency keys for neverLose endpoints.
  • Treat duplicate keys as the same business operation.
  • Return clear 4xx when the client should stop retrying (conflict strategies can help).

When not to use Eidos

  • You only need online cache + retry UI → TanStack Query is enough.
  • You only need SW asset caching → Workbox may be enough.
  • You need multiplayer CRDT sync as the core product → look at dedicated CRDT tools (Eidos has optional packages; they are not the main pitch).

Deeper guides in the repo: guarantees.md · troubleshooting.md · Advanced docs