Connection lost. Actions kept.
The tracker’s own web interface is designed around a durable local queue. Prepared actions stay on your device while waiting for a connection.
This does not mean every operation is available offline: opening an installation for the first time, signing in and fetching uncached data require connectivity.
Different states, different guarantees
| State | Meaning |
|---|---|
| Saved on device | The action is stored locally, but not confirmed by the server |
| Sending | The client is waiting for a response |
| Confirmed by server | The server accepted the change |
| Error | The action failed and its reason is visible |
| Conflict | Server data changed; a person must decide what to keep |
Try the sequence
Disconnect in the example, save the sample task, then reconnect. This is a state model: it does not change your network settings or make requests.
Retry without another task
Retries preserve an operation’s identifier, distinguishing a new task from another delivery of the same action. If a response is lost, the client checks the server’s record.
A task should not appear twice just because its response failed to arrive.
When data has changed
Version conflicts require comparison and an explicit decision. Newer data is not silently overwritten. Resolving a conflict creates a new operation.
After restoring a server backup, old local actions remain available for reconciliation. They must not be automatically replayed against the new server history.
Important boundaries
- A queue belongs to a particular installation and account.
- Signing out with unsent actions requires a warning.
- If the browser cannot store an action, it must not claim it was saved locally.
- The durable queue belongs to the tracker’s own web interface. The GrigDesk driver does not promise the same recovery after a client restart.