Sync & Conflicts

This page covers the sync behavior of Computtite cloud mode workspaces. Understanding it helps you diagnose issues and reason about how conflicts are resolved when multiple people edit simultaneously.

Sync Status States

The sync status indicator located in the sidebar footer and top bar shows the real-time sync state for cloud workspaces:

• idle / synced: No active transfer. Local SQLite cache is consistent with Supabase.
• syncing: An asynchronous push/pull cycle is currently executing.
• offline: Network connectivity is unavailable. Local mutations are queued safely in sync_operations within SQLite and will push immediately upon reconnection.
• error: The last sync attempt failed after retry backoff. Hover over or click the indicator to view diagnostic details.

How the Sync Engine Works

Every data mutation (create, edit, delete) writes to local SQLite repositories first, ensuring zero UI latency. In cloud mode, mutations append to a durable sync_operations queue table. Every 10 seconds, the background sync worker flushes pending operations to Supabase and pulls remote changes using per-table updated_at cursors stored in sync_cursors.

Conflict Resolution

When concurrent updates occur on the same record across different clients, Computtite resolves the state using a deterministic last-write-wins strategy based on remote timestamps. All operations are permanently captured in the audit timeline, maintaining accountability.

Offline Resilience & Queue Persistence

Pending operations persist in the local SQLite database across application restarts and operating system reboots. If you edit assets while disconnected on a flight or in a warehouse, closing the application loses zero data: Computtite automatically flushes the queue the moment internet connectivity returns.