TriportRPC

RPC error -32001: Block cleaned up, does not exist on node

Last updated:

At a glance

Error details
PropertyValue
Code-32001
MessageBlock cleaned up, does not exist on node
Categoryblock

Cause

-32001 means the block for this slot did exist on the node and has since been removed by its ledger-retention cleanup — the node served it once, at some point in the past, and simply no longer holds it now. That is what actually separates it from the other three getBlock slot errors, which are easy to lump together as "slot too old" but describe three different histories. -32004 ("Block not available for slot") is the vaguer, catch-all code: the slot may be ahead of the node's current position (the future) or may have aged out — it does not distinguish a block that once existed from one that never will. -32007 and -32009 both describe a slot the leader skipped: no block was ever produced for it, so there was nothing to retain in the first place — -32007 when the node's own ledger jumped past it after restoring from a snapshot, -32009 when it is simply absent from long-term (warehouse) storage. -32001 is the only one of the four that confirms a block did exist: the node's own error text carries the retention boundary directly, naming the requested slot next to its current first available block.

Solution

  1. Read the first-available-block boundary straight out of the error text — the node states it next to the slot you asked for, so you do not need a second call just to learn where the cutoff is.
  2. Before backfilling a range, compare the oldest slot you plan to request against the current result of getFirstAvailableBlock: anything below it will return -32001, not a block.
  3. For genuinely old slots, query a node with deeper ledger retention (an archival endpoint) rather than retrying the same one — the pruned data is gone from that node, not delayed.
  4. Do not retry the same slot against the same node in a loop expecting it to come back — -32001 is deterministic, and the boundary only moves forward as the node prunes further, never backward.
  5. If the slot was never produced at all rather than pruned after being produced, getBlock answers -32007 or -32009 instead of -32001 — check the code before assuming which situation you are in.

Example

{
  "id": 1,
  "error": {
    "code": -32001,
    "message": "Block 123456789 cleaned up, does not exist on node. First available block: 130000000"
  },
  "jsonrpc": "2.0"
}

FAQ

Why does "Block cleaned up, does not exist on node" happen?
-32001 means the block for this slot did exist on the node and has since been removed by its ledger-retention cleanup — the node served it once, at some point in the past, and simply no longer holds it now. That is what actually separates it from the other three getBlock slot errors, which are easy to lump together as "slot too old" but describe three different histories. -32004 ("Block not available for slot") is the vaguer, catch-all code: the slot may be ahead of the node's current position (the future) or may have aged out — it does not distinguish a block that once existed from one that never will. -32007 and -32009 both describe a slot the leader skipped: no block was ever produced for it, so there was nothing to retain in the first place — -32007 when the node's own ledger jumped past it after restoring from a snapshot, -32009 when it is simply absent from long-term (warehouse) storage. -32001 is the only one of the four that confirms a block did exist: the node's own error text carries the retention boundary directly, naming the requested slot next to its current first available block.
How do I fix "Block cleaned up, does not exist on node"?
Read the first-available-block boundary straight out of the error text — the node states it next to the slot you asked for, so you do not need a second call just to learn where the cutoff is. Before backfilling a range, compare the oldest slot you plan to request against the current result of getFirstAvailableBlock: anything below it will return -32001, not a block. For genuinely old slots, query a node with deeper ledger retention (an archival endpoint) rather than retrying the same one — the pruned data is gone from that node, not delayed. Do not retry the same slot against the same node in a loop expecting it to come back — -32001 is deterministic, and the boundary only moves forward as the node prunes further, never backward. If the slot was never produced at all rather than pruned after being produced, getBlock answers -32007 or -32009 instead of -32001 — check the code before assuming which situation you are in.