Offline queue

The offline-queue subpath wraps your sender so that failed sends survive page reloads and offline periods. Bundle target: ≤ 1.5 kB gzip.

Install

import { installOfflineQueue } from '@syntarie/tracking/offline-queue';
import { send } from '@syntarie/tracking';

const { send: queuedSend, teardown } = installOfflineQueue(send);

// Use queuedSend instead of send for any module that should survive offline:
queuedSend(event);

installOfflineQueue returns the wrapped sender plus a teardown for HMR.

Behaviour

• A sender that resolves is considered successful — the event is not persisted.
• A sender that rejects persists the event to IndexedDB.
• On the next successful send (network back) the queue drains FIFO until empty or the next failure.
• On the browser online event the queue drains opportunistically.

Capacity

The queue is hard-capped at 1000 events. Above the cap, the oldest event is evicted to make room for the new one. The bounded size is a deliberate constraint — an unbounded queue on a long-offline device can exhaust IndexedDB quota.

Options

installOfflineQueue(send, { dbName: 'syntarie_offline_queue' });

Option	Type	Default
dbName	string	'syntarie_offline_queue'

You only need to override dbName if you run multiple Leatsmap SDK instances on the same origin (rare).

Combining with retry

The offline queue handles persistence across reloads. The retry module handles in-memory exponential backoff during a single page lifetime. The two are complementary: wrap the sender with retry first, then the offline queue, and you get both.

Browser support

Requires IndexedDB. The module is a no-op on browsers that do not have it (extremely rare in v1.0 — every supported target ships IndexedDB).