Slot skipped — missing messages in stream

Root causes

Ranked by frequency. First cause is the one to check first.

1. 01Network-skipped slots: Solana validators didn't produce blocks at those heights. This is a protocol-level event, not an infrastructure problem. ~1–3% of slots are skipped under normal conditions.
2. 02Consumer backpressure: your processing loop is too slow, the server's HTTP/2 flow control window fills, and the provider drops buffered messages rather than pile up latency.
3. 03Provider-side failover: a brief gap during a server restart. Subglow maintains hot-standby and a 2s gap is the worst case.

Fix steps

1. 1

   Distinguish network skips from consumer drops

   Subscribe to `slots_update` alongside transactions. You'll see every slot status transition, including skipped. If the skipped slot appears in slots_update but the corresponding transactions don't arrive, you've been throttled — your consumer was too slow.

2. 2

   Fix the slow consumer

   Make the inner loop O(1) — never do a blocking DB write or HTTP call inside the `for await`. Push parsed updates to an async queue and process them in parallel. The gRPC stream should be the fastest thing in your pipeline.

3. 3

   Backfill via JSON-RPC

   For slots you missed, call `getBlock(slot, { transactionDetails: 'full', maxSupportedTransactionVersion: 0 })` on your RPC endpoint and reparse. This is how production sniper bots achieve zero-miss: they gRPC-stream the live edge and JSON-RPC-backfill any gap.

Related errors

• CANCELLED — stream closed unexpectedly
  `Status { code: Cancelled }` on an active stream almost always means the TCP connection was closed by a middlebox (Kubernetes pod restart, load balancer, NAT timeout). It's not an error in the programmer sense — it's a normal event to handle with reconnect logic.
• DEADLINE_EXCEEDED on Yellowstone subscribe
  `Status { code: DeadlineExceeded }` means the RPC didn't produce a response within the deadline you (or the default) set. On a streaming subscribe this usually means the initial handshake took too long, or the client's deadline was accidentally set on the whole stream instead of the initial call.
• RESOURCE_EXHAUSTED — rate limit on gRPC
  `Status { code: ResourceExhausted }` means the server refused to serve your call because you hit a limit — concurrent streams, messages-per-second, or filter complexity. Unlike HTTP 429, this is a hard rejection: the stream is closed and must be reconnected, not retried on the same channel.