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.
Provider source exists, but dormant source is not a supported offline feature. Do not document, test, or promise offline order changes or replay for the current release.
Availability
Current-release disposition: excluded for productive procedures. Re-entry requires an explicit provider-mount product decision, accepted queue/replay semantics, authorization, conflict/idempotency, failure retention, cleanup and zero-effect testing.
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