Offline Mode

When your connection drops, Routebase does not. Your changes are written to a local database, queued, and sent to the server the moment you are back — without you doing anything about it.

This works in the browser too, not only in the desktop app. A dropped Wi-Fi connection, a tunnel, a flaky conference network: the behaviour is the same in both clients.

What you see

Two pieces of interface tell you where you stand.

The offline banner appears across the top as soon as the browser reports no connection:

You're offline. Changes are saved locally and will sync automatically when you reconnect.

The sync indicator sits in the header and shows the state of the queue. It appears when there is something to report and stays out of the way otherwise:

Clicking it opens a panel with the counts, whether you are online or offline, and the actions described below.

How it works

Every change you make goes through the same path whether or not you are online: it is written to a local IndexedDB store, added to a sync queue, and executed against the API. When there is no connection, only the last step waits.

The queue drains automatically — when the connection comes back, when the app starts, and periodically while it runs. You do not have to open the indicator for anything to happen.

stateDiagram-v2
    state "In the sync queue" as Q
    state "Done" as D
    state "Failed" as F
    state "Concurrency conflict" as CC
    state "Cascade conflict" as CD

    [*] --> Q: you edit — online or not
    Q --> D: the server accepts it
    Q --> F: the server rejects it
    Q --> CC: the server holds a newer version
    Q --> CD: the create it depends on never landed

    F --> Q: Retry now
    CC --> Q: auto-retry, once or twice

    note right of CC: when the auto-retries run out,<br/>open the entity and decide
    note right of CD: retrying cannot help —<br/>discard, or fix the original create

Editing is covered across the product: projects, API design (endpoints, schemas, components and shared library), documentation, testing and test data, mock server, monitoring, governance, notifications and organization settings all have offline support. Reading is served from the cached data you already loaded.

What offline mode does not do is run things that only exist on the server. A test run, a security scan, a mock request, a portal build — those need the backend and wait for it. Offline mode is about not losing your edits, not about a local copy of Routebase.

Failed items

An item is failed when the server rejected it — a validation error, a permission it turns out you do not have, something deleted underneath you.

The panel offers Retry now, which puts failed items back in the queue. If the cause was temporary, they go through. If it was not, they fail again, and the change needs looking at in the app.

Conflicts

A conflict is the interesting case: your queued change collided with a newer state on the server. Somebody edited the same thing while you were offline.

Two kinds exist, and the panel tells you which you have:

Concurrency conflicts — the server has a newer version of the entity than the one your change was based on. Routebase retries these once or twice on its own, because the common cause is a concurrent edit that a re-fetch resolves. When automatic retries run out, the panel says so:

n conflicts reached the auto-retry cap. Try again or open the entity to review the latest server version.

Retry conflicts tries again. If it keeps failing, open the entity in the app: you are looking at a genuine disagreement about what the current value should be, and that is a decision rather than a retry.

Cascade conflicts — a change that depends on something that was never created. If a create fails while offline, everything you built on top of it references an object that does not exist. Retrying cannot help, so Routebase does not:

Conflicts are unrecoverable (parent create failed). Discard or fix manually.

The way out is to fix the original create — or discard the dependent changes and redo them now that you can see what actually exists on the server.

Practical notes

• The queue is per browser and per device. Changes made offline on your laptop sync from that laptop. Opening Routebase somewhere else will not find them until the first device syncs.
• Don't clear site data with a queue outstanding. The queue lives in that store; clearing it discards unsynced changes.
• Check the indicator before you close. If it shows pending items, give it a moment on a connection first.

Related

• Desktop App — the native macOS and Windows clients
• Spec Versioning — conflict handling for two people editing the same spec online