starknet_syncing incorrectly reports "not syncing" in pruned mode

[EgeCaner]

Summary

In pruned mode, Handler.Syncing (rpc/(v10/v9/v8)/sync.go) can return false (not syncing) while the node is in fact still syncing. This happens because it reads the starting block's header solely to obtain that block's hash, and in pruned mode that header may have already been pruned, so the read fails and the handler falls through to the default "not syncing" response.

Details

The handler resolves the starting block hash like this:

  startingBlockNumber, err := h.syncReader.StartingBlockNumber()
  if err != nil {
      return defaultSyncState, nil
  }
  startingBlockHeader, err := h.bcReader.BlockHeaderByNumber(startingBlockNumber)
  if err != nil {
      return defaultSyncState, nil   // <-- pruned starting header lands here
  }

BlockHeaderByNumber(startingBlockNumber) is called only to read startingBlockHeader.Hash (and .Number, which we already have). When the node runs with history pruning enabled and has been syncing long enough that the starting block falls outside the retained window, that header no longer exists in the DB. The lookup returns an error, and every error path in this function returns defaultSyncState, i.e. Syncing: false.

The result: a node that is actively syncing reports itself as fully synced, which is misleading to clients and breaks anything that polls starknet_syncing to gate readiness.

[cicr99]

One related nuance: regardless of pruning mode, there is a short startup window where starting_block_hash is not available yet.

syncBlocks sets startingBlockNumber to head + 1 when the sync loop starts. At that moment, that block has not been stored locally yet, so the current RPC implementation cannot read its header from the DB. In practice, starknet_syncing may briefly return false until that first block is stored.