What causes "missing block data" in hyperledger/fabric?

Inspect the producer of the block for swallowed unmarshal/partial-read errors and fail fast on them.

missing block data

Error message

missing block data

What it means

VerifyBlockHash found that the block at indexInBuffer has a nil Data field. Without the block's payload, protoutil.BlockDataHash cannot compute the data hash to compare against the header, so verification aborts. Like the missing-header error, it indicates uninitialized or corrupt block data rather than a hash mismatch.

Source

Thrown at orderer/common/cluster/util.go:227

type BlockSequenceVerifier func(blocks []*common.Block, channel string) error

// Dialer creates a gRPC connection to a remote address
type Dialer interface {
	Dial(endpointCriteria EndpointCriteria) (*grpc.ClientConn, error)
}

// VerifyBlockHash verifies the hash chain of the block with the given index
// among the blocks of the given block buffer.
func VerifyBlockHash(indexInBuffer int, blockBuff []*common.Block) error {
	if len(blockBuff) <= indexInBuffer {
		return errors.Errorf("index %d out of bounds (total %d blocks)", indexInBuffer, len(blockBuff))
	}
	block := blockBuff[indexInBuffer]
	if block.Header == nil {
		return errors.New("missing block header")
	}
	if block.Data == nil {
		return errors.New("missing block data")
	}
	seq := block.Header.Number
	dataHash, err := protoutil.BlockDataHash(block.Data)
	if err != nil {
		return err
	}
	// Verify data hash matches the hash in the header
	if !bytes.Equal(dataHash, block.Header.DataHash) {
		computedHash := hex.EncodeToString(dataHash)
		claimedHash := hex.EncodeToString(block.Header.DataHash)
		return errors.Errorf("computed hash of block (%d) (%s) doesn't match claimed hash (%s)",
			seq, computedHash, claimedHash)
	}
	// We have a previous block in the buffer, ensure current block's previous hash matches the previous one.
	if indexInBuffer > 0 {
		prevBlock := blockBuff[indexInBuffer-1]
		currSeq := block.Header.Number
		if prevBlock.Header == nil {

View on GitHub (pinned to 2736b63f8f)

Solutions

Inspect the producer of the block for swallowed unmarshal/partial-read errors and fail fast on them.
Pre-validate blocks (nil Header and Data checks) before pushing into the buffer used by VerifyBlockHash.
Re-pull the affected blocks from a healthy orderer; if corruption persists, check ledger storage health (fileLedger/blockStore).

Example fix

// before
seq := block.Header.Number
dataHash, _ := protoutil.BlockDataHash(block.Data)
// after
if block.Data == nil {
    return errors.New("block data is missing, cannot verify hash")
}
dataHash, err := protoutil.BlockDataHash(block.Data)
if err != nil {
    return err
}

Defensive patterns

Strategy: validation

Validate before calling

if b == nil || b.Header == nil || b.Data == nil {
    return errors.New("cannot verify block: header or data missing")
}
// safe to call cluster.VerifyBlockHash now

Type guard

func isCompleteBlock(b *common.Block) bool {
    return b != nil && b.Header != nil && b.Data != nil
}

Prevention

Check unmarshal and partial-read errors when receiving blocks over the wire.
Only append fully populated blocks (Header and Data set) to buffers used for verification.
Investigate storage health if incomplete blocks recur from the local ledger.

When it happens

Trigger: A common.Block is placed into blockBuff with Header set but Data nil — typically from a truncated/garbled unmarshal during block pull, or from manually constructed blocks in tests/benchmarks.

Common situations: Interrupted block replication delivering partial payloads; corrupted file ledger entries; test code building common.Block structs without populating Data.

Related errors

AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04). Data as JSON: /api/errors/ba2a5cce7cf4a6c5. Report an issue: GitHub.