Client-side operation queue with retry & exponential backoff

[FuJacob]

Context

Currently, all WebSocket messages in useCanvasCollab.ts are fire-and-forget — if the WebSocket is open, the message is sent with no confirmation, no retry, and no durability. Dropped messages on network glitches are silently lost.

Sim's architecture uses a client-side Operation Queue that ensures no operation is lost, even under poor network conditions.

What to build

Operation Queue Store

• New store (or hook) that maintains a FIFO queue of pending operations
• Each operation has: id, operation (type + target + payload), workflowId, userId, status (pending/in-flight/failed)
• Queue processor sends one operation at a time, waiting for server acknowledgment before proceeding to the next

Retry with exponential backoff

• Structural changes (node create/delete/move, edge create/delete): 3 retry attempts
• Value changes (text edits, subblock updates): 5 retry attempts
• Exponential backoff between retries

Offline mode fallback

• After all retries exhausted, enter offline/read-only mode
• Clear the queue and notify the user
• Recovery requires manual refresh

Debouncing & coalescing

• Text edits (CRDT ops, node content updates) should be debounced client-side before enqueueing
• Consecutive same-type ops on same target should coalesce (e.g., 500 keystrokes → ~10 queued ops)

Current code references

• frontend/src/canvas/hooks/useCanvasCollab.ts — current send() function (fire-and-forget)
• frontend/src/shared/events.ts — CanvasOutboundEvent type definitions

Acceptance criteria

• Operations survive brief network interruptions (WebSocket reconnect)
• Failed ops retry with backoff before giving up
• Text edits are debounced/coalesced to reduce message volume
• Queue processes in FIFO order, one at a time
• Offline mode activates when retries exhausted