Offline and outbox

​

How offline works

​

localStorage outbox

​

Entry structure

interface OutboxEntry {
  id: string;                    // UUID
  action: "orders/create" | "orders/update";
  payload: Record<string, unknown>;
  createdAt: string;             // ISO timestamp
  attempts: number;              // Number of send attempts
  nextAttemptAt: string | null;  // Earliest retry time
  lastError: string | null;      // Last failure message
}

​

Queuing

queueOutbound("orders/create", {
  pos_reference: "POS-001-0001-00001",
  lines: [...],
  amount_total: 150.00,
});

​

Flushing

1. Reads all entries from localStorage
2. Filters entries where nextAttemptAt <= now (respects backoff)
3. For each entry, sends POST /pos-react/api/orders/{action} to Odoo
4. On success: removes entry from queue
5. On failure: increments attempts, computes next retry time, stores error

​

Retry backoff

​

Outbox depth monitoring

​

Hub-side event log

CREATE TABLE events (
  id            INTEGER PRIMARY KEY AUTOINCREMENT,
  type          TEXT NOT NULL,     -- 'order_snapshot', 'table_update', etc.
  pos_reference TEXT,
  terminal_id   TEXT,
  payload       TEXT,              -- JSON
  forwarded     INTEGER DEFAULT 0, -- 0=pending, 1=forwarded to Odoo
  created_at    TEXT DEFAULT (datetime('now'))
);

​

Forwarder

1. Runs every 5 seconds (FORWARD_INTERVAL_MS)
2. Queries up to 20 pending events (FORWARD_BATCH_SIZE), oldest first
3. Non-order events are marked as forwarded immediately (no Odoo action needed)
4. Order snapshot events are forwarded via the Odoo adapter
5. On success: marks events as forwarded=1
6. On first failure: logs error, stops processing batch (preserves ordering)

​

Idempotency

• Odoo’s create endpoint returns the existing order if the reference already exists
• The hub’s orderStore.upsert() uses INSERT OR REPLACE keyed by pos_reference
• The outbox deduplicates by pos_reference before queuing

​

Visibility