Reliability
A reconnected socket does not mean an up-to-date screen
A customer leaves an order page open, closes their laptop, and returns after the order has shipped. The connection comes back. What should the page show? Opening a new socket restores a path for future events; your application still needs to recover the changes that happened while it was away.
Treat connection and freshness as separate states
A connected indicator tells you about the transport. It does not prove that the interface has the latest order, message history or dashboard totals. pubb delivers events to currently connected subscribers, so design recovery around the saved data your application can fetch. Do not assume that reconnecting replays everything a client missed.
Represent the difference in the interface. While disconnected, keep the last useful view visible where appropriate and show that updates are paused. After reconnecting, show that the view is refreshing until the authoritative data arrives. Avoid presenting old information as current merely because the socket is open again.
Restore subscriptions before reconciling
A recovery flow needs to reconnect, restore the relevant channel subscriptions, and refresh the saved state. Restricted channels also need valid authorization for the new connection. Check the behavior of the client you use: pubb’s JavaScript SDK automatically resubscribes on reconnect, while a native WebSocket integration needs its own reconnect and resubscription logic.
Subscription recovery still leaves state recovery to the application. Begin reconciling after the relevant subscription is confirmed, and account for events that arrive while the state request is in flight. Simply fetching a snapshot and then subscribing can leave a gap between those two operations. Subscribe first, observe incoming changes, and use a reconciliation rule that prevents an older response from overwriting newer information.
Use versions when updates can overlap
For an order page, your application can assign each saved order update a monotonically increasing version. Return that version with the order snapshot and include it in the events you publish. If an incoming full-state event describes version 19 and a slower request returns version 18, keep version 19. The version belongs to your application’s data model; it is not a delivery sequence supplied by pubb.
Partial updates need more care. Applying only the latest patch may skip an earlier change to another field. Buffer and apply consecutive patches against a known snapshot, or fetch the latest record when you detect a gap. For a simpler implementation, treat events as invalidation signals: mark the resource stale and refetch it. If another event arrives during the request, schedule another refresh so an in-flight response cannot silently clear that change.
Keep recovery bounded and visible
If you manage a native connection yourself, space retry attempts with a capped backoff and add jitter so clients do not all retry at the same instant. If an SDK manages reconnection, use its lifecycle and retry controls instead of wrapping it in a competing reconnect loop. When automatic attempts stop, give the user a clear retry action.
Also clean up event listeners and subscriptions when a view is removed. Repeatedly opening a page should not create several handlers for the same event. Recovery should restore one active view of the resource, without accumulating duplicate notifications or requests behind the scenes.
Test the return journey
A useful recovery test starts with a subscribed client, disconnects it, changes the resource through another client, and then reconnects. The returning screen should converge on the saved state even though it missed an event. Repeat the test with a delayed snapshot response and a new event arriving during that delay.
Check duplicate event handling, denied subscriptions and exhausted retries as separate cases. These exercises reveal whether your product can explain what is happening and recover without a page reload. A realtime feature earns trust when the next live update arrives quickly and the return after an interruption is equally predictable.