---
title: "Driver App offline actions"
description: "Use the reviewed current-release exclusion and fail-closed requirements for offline replay."
canonical: https://docs.ordering.co/docs/developers/driver-app/offline-actions/
---

# 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](https://docs.ordering.co/docs/developers/driver-app/architecture/) · [Background execution](https://docs.ordering.co/docs/developers/driver-app/background-execution/) · [Order mutation contract](https://docs.ordering.co/docs/developers/driver-app/order-mutation-contract/) · [Order state reference](https://docs.ordering.co/docs/developers/driver-app/order-state-reference/)