Use the reviewed offline actions contract
The reviewed Driver App release does not mount its offline-actions provider in the productive provider tree. Consumers therefore receive default context: offline saving is disabled, action methods are no-ops, and controls that depend on offline capability remain hidden or disabled.
The offline-actions provider is inactive, so offline order changes and replay are unavailable in the current release.
Availability
Offline actions are unavailable in the current release. Do not rely on queued order changes or automatic replay after reconnecting.
Prerequisites
- Product approval for exactly which actions may be queued offline.
- Mounted provider and explicit enabled state, never default truthiness.
- Durable queue schema with account/project/order ownership and generation.
- Ordered, awaited replay with retry, conflict and idempotency contracts.
- Per-action/server receipts before removal from durable storage.
- No derived message, status or group action unless independently authorized.
Responsibility boundaries
| Boundary | Current responsibility | Limit |
|---|---|---|
| Productive provider tree | Does not mount offline provider. | Offline feature unavailable. |
| Default context | Reports offline saving disabled and inert methods. | No queue/replay behavior. |
| Dormant provider | Contains local queue/order-cache/reconnect replay intent. | Source presence is not release behavior. |
| Local storage | Could hold queued action map and cached order groups if provider were mounted. | Durability, encryption, ownership and cleanup unproven. |
| Replay | Could choose the last change per order and derive messages for earlier changes. | Async operations are not awaited as one flow. |
| API | Must authorize each replayed status/message independently. | Client queue cannot preserve old eligibility. |
Inputs and result
| Input/state | Dormant-source behavior | Failure boundary |
|---|---|---|
| Default current context | Save actions are disabled/no-op and have no accepted result. | No supported offline outcome. |
| Offline action while enabled | Append action under order and write local queue. | Account/order ownership and durability unproven. |
| Cached order update | Move/update order among local status groups. | Client state can diverge from server. |
| Connectivity restored | Read queue and call replay. | Replay launch is not awaited. |
| Multiple queued changes | Reverse list, send derived message for earlier changes, save last status. | Message/status ordering and authorization are separate. |
| Replay cleanup | Remove durable queue and clear local actions after scheduling work. | Source clears before asynchronous per-order operations reliably settle. |
Security and privacy
- Never store real order bodies, messages, tokens, PII or location in an unreviewed offline queue.
- Reauthorize every action against current order/account state at replay time.
- Do not encode discarded changes into messages without explicit product, authorization and privacy review.
- Bind queues to account/project generation and erase them only after accepted receipts or explicit quarantine.
Limits and failure states
| State | Meaning | Required response |
|---|---|---|
| Current default context | Offline saving disabled. | Keep procedures excluded. |
| Provider code present | Dormant implementation only. | Do not infer reachability. |
| Replay scheduled | Async per-order work started. | Do not clear queue yet. |
| Partial status/message failure | Some operations return null or are swallowed. | Preserve/quarantine each failed item. |
| Queue cleared early | Durable evidence removed before completion. | Blocking correctness defect. |
| Group action hidden | Default context prevents productive route/control. | Do not expose dedicated group procedure. |
Troubleshooting
If a current build appears to allow offline mutation, stop: verify provider-tree authority and release composition before trusting UI. Never simulate reconnect against real orders. Inspect only synthetic queue ownership, awaited operation ledger, receipts, retry/conflict/idempotency and cleanup in a zero-effect harness.
Re-review whenever provider mounting, default context, queue schema, replay ordering, derived messages, status authorization, cached groups or cleanup changes.
Related guides: Driver App architecture · Background execution · Order mutation contract · Order state reference