What causes "timeout waiting for channel creation" in hyperledger/fabric?

Re-run with a longer timeout: --timeout 30s (or higher).

timeout waiting for channel creation

Error message

timeout waiting for channel creation

What it means

getGenesisBlock polls the orderer's deliver service for block 0 (the channel genesis block) after submitting a create transaction. If the genesis block is not delivered within the configured timeout (default ~10s via --timeout), it gives up and reports 'timeout waiting for channel creation', since without block 0 creation cannot be confirmed.

Source

Thrown at internal/peer/channel/create.go:212

	}
	err = os.WriteFile(file, b, 0o644)
	if err != nil {
		return err
	}

	return nil
}

// deprecated
func getGenesisBlock(cf *ChannelCmdFactory) (*cb.Block, error) {
	timer := time.NewTimer(timeout)
	defer timer.Stop()

	for {
		select {
		case <-timer.C:
			cf.DeliverClient.Close()
			return nil, errors.New("timeout waiting for channel creation")
		default:
			if block, err := cf.DeliverClient.GetSpecifiedBlock(0); err != nil {
				cf.DeliverClient.Close()
				cf, err = InitCmdFactory(EndorserNotRequired, PeerDeliverNotRequired, OrdererRequired)
				if err != nil {
					return nil, errors.WithMessage(err, "failed connecting")
				}
				time.Sleep(200 * time.Millisecond)
			} else {
				cf.DeliverClient.Close()
				return block, nil
			}
		}
	}
}

// deprecated
func create(cmd *cobra.Command, args []string, cf *ChannelCmdFactory) error {

View on GitHub (pinned to 2736b63f8f)

Solutions

Re-run with a longer timeout: --timeout 30s (or higher).
Verify the orderer is running and reachable (logs, `docker ps`, port connectivity).
Check orderer logs for the channel creation/consensus errors; fix TLS certs or genesis profile issues.
Retry the create after the cluster settles — the channel may actually exist, so check with `peer channel list` first.

Example fix

// before
peer channel create -o orderer:7050 -c mychannel -f mychannel.tx
// after
peer channel create -o orderer:7050 -c mychannel -f mychannel.tx --timeout 60s

Defensive patterns

Strategy: retry

Validate before calling

nc -z orderer.example.com 7050 || { echo "orderer unreachable" >&2; exit 1; }
peer channel create ... --timeout 60s

Try / catch

err := cmd.Execute()
if err != nil && strings.Contains(err.Error(), "timeout waiting for channel creation") {
    // check `peer channel list`, then retry with larger --timeout
}

Prevention

Set a generous --timeout in scripts and CI.
Ensure orderers are healthy and RAFT leader elected before creating channels.
Verify TLS CA configuration for the orderer connection.
After a timeout, check whether the channel actually exists before retrying.

When it happens

Trigger: Running `peer channel create` where the orderer never returns block 0 within the timeout: slow consensus, orderer not actually started, TLS/cert mismatch preventing deliver, or very slow HSM signing.

Common situations: Orderer container still bootstrapping;RAFT leader election delay in a multi-node ordering service; wrong orderer TLS CA in the peer config; network latency between peer and orderer; GENESIS block retrieval behind a proxy that drops idle streams.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

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