Subscriptions

Polling works, and for most applications it is enough. When it is not, the context can subscribe to account updates instead.

Subscriptions are context-owned, which is the important detail: an update arriving over a subscription goes through the same validation and lands in the same cache as a normal read. A subscribed fleet and a fetched fleet are the same cached snapshot, not two views that can disagree.

What that buys you

Without shared identity, a live update and a fetch race each other, and which one your application sees depends on timing. Here they cannot diverge: both write to the same cache slot under the same key.

Updates are translated the same way reads are, so a subscription delivers the SDK’s own snapshot types rather than raw account bytes.

Reconnection

Connections drop. When one does, the SDK resynchronises rather than resuming blindly, because the gap between disconnect and reconnect is exactly where missed updates hide.

Reconnects coalesce: a burst of drops produces one resynchronisation rather than one per drop, and a reconnect that arrives while another is in flight is folded into it rather than queued behind it.

Cancellation

Subscriptions are cancellable, and disposing a context cancels everything it owns. That matters in a browser, where a component unmounting must not leave a socket delivering updates into a cache nobody reads.

When to reach for this

Prefer polling with a sensible maxAge unless you have a reason not to. It is simpler, it degrades more gracefully, and for state that changes on the scale of minutes it is indistinguishable to a user.

Subscribe when you are tracking something that genuinely moves — an active fleet, an order book — and staleness is visible.

Reference

• client — subscription exports
• Caching and provenance — the cache updates land in