slotUnsubscribe

slotUnsubscribe stops a slot heartbeat opened with slotSubscribe on the same WebSocket connection. Pass the integer subscription id from the subscribe ack; the server responds result: true and the ~2.5-per-second slotNotification frames for that id cease. The connection itself, and any other subscriptions multiplexed on it, continue unaffected.

A slot stream is unusual among Pub/Sub families in that it never goes quiet on its own — it produces a frame for every slot the node processes, around 216,000 frames a day, whether or not anyone is looking. That makes explicit teardown worthwhile the moment the consumer disappears: a dashboard tab showing the live slot ticker is closed, a benchmark that was measuring notification latency has finished its run, or a transaction-expiry countdown completed because the transaction confirmed. Applications that only needed the heartbeat as a temporary liveness probe during startup should also drop it once their real subscriptions are flowing, rather than paying the per-frame overhead for the life of the connection.

The standard lifecycle caveats apply. The id is only valid on the session that created it: after a reconnect the server has forgotten every subscription, so calling slotUnsubscribe with a remembered id fails with -32602 (invalid subscription id) — the correct recovery is simply not to resubscribe. The same error appears if you unsubscribe twice, since the first call already removed the id. Because slot frames are emitted so frequently, it is normal for one or two notifications to arrive after you send the unsubscribe but before the ack — drop frames for ids you no longer track. If the whole session is ending anyway, closing the socket releases this and every other subscription in one step; no per-id cleanup is required.