hyperledger/fabric · error
proto: Marshal called with nil
Error message
proto: Marshal called with nil
What it means
After fetching, the command sanity-checks that the delivered block is non-nil before proto.Marshal. A nil block would make the protobuf marshal panic ('proto: Marshal called with nil'), so fetch returns this error defensively when the deliver client returned success but no block.
Source
Thrown at internal/peer/channel/fetch.go:97
lc, err2 := protoutil.GetLastConfigIndexFromBlock(iBlock)
if err2 != nil {
return err2
}
logger.Infof("Retrieving last config block: %d", lc)
block, err = cf.DeliverClient.GetSpecifiedBlock(lc)
default:
num, err2 := strconv.Atoi(args[0])
if err2 != nil {
return fmt.Errorf("fetch target illegal: %s", args[0])
}
block, err = cf.DeliverClient.GetSpecifiedBlock(uint64(num))
}
if err != nil {
return err
}
if block == nil {
return errors.New("proto: Marshal called with nil")
}
b, err := proto.Marshal(block)
if err != nil {
return err
}
var file string
if len(args) == 1 {
file = channelID + "_" + args[0] + ".block"
} else {
file = args[1]
}
if err = os.WriteFile(file, b, 0o644); err != nil {
return err
}
return nilView on GitHub (pinned to 2736b63f8f)
Solutions
- Retry the fetch; transient deliver issues often resolve.
- Check orderer logs for errors serving the requested block.
- Verify connectivity to the orderer without intermediaries (bypass proxies).
- If persistent, ensure orderer and peer versions are compatible.
Example fix
// not applicable — defensive internal check; fix is operational (retry/repair orderer connectivity)
Defensive patterns
Strategy: retry
Validate before calling
// pre-check channel exists and orderer is healthy peer channel list curl -s --cacert ca.pem https://orderer.example.com:7050/healthz 2>/dev/null || echo 'check orderer health endpoint'
Try / catch
if err := cmd.Execute(); err != nil {
if strings.Contains(err.Error(), "proto: Marshal called with nil") {
// nil block from deliver; retry fetch, inspect orderer logs
}
} Prevention
- Retry fetches on transient deliver failures.
- Keep orderer and peer on compatible versions.
- Avoid proxies/LBs that can truncate long-lived deliver streams.
- Monitor orderer logs for block-serving errors.
When it happens
Trigger: Deliver client returns no error but a nil block — e.g. a malformed/edge-case response from the orderer or an unexpected empty stream after GetSpecifiedBlock/GetNewestBlock.
Common situations: Orderer misbehaving or returning an empty response; proxy/load-balancer truncating the deliver stream; bugs in custom deliver implementations; race where the channel was deleted or reset.
Related errors
- response error: unknown type %T
- error unmarshalling
- error encoding output
- error unmarshalling original config
- error unmarshalling updated config
AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04).
Data as JSON: /api/errors/f6cf7535673a0305.
Report an issue: GitHub.