hyperledger/fabric · error

could not connect to ordering service, orderer-address: %s

Error message

could not connect to ordering service, orderer-address: %s

What it means

FetchBlocks attempts d.requester.Connect(seekInfoEnv, source) to open a deliver stream to one orderer endpoint; on failure it logs a warning and pushes an error wrapping the cause with the orderer address into fetchErrorsC. DeliverBlocks aggregates these, so block fetching for that source fails. Unlike error 215, this is a per-fetch-source failure that is reported through a channel rather than aborting setup.

Source

Thrown at common/deliverclient/blocksprovider/bft_deliverer.go:351

	for {
		select {
		case <-d.DoneC:
			fetchErrorsC <- &ErrStopping{Message: "stopping"}
			return
		default:
		}

		seekInfoEnv, err := d.requester.SeekInfoBlocksFrom(d.getNextBlockNumber())
		if err != nil {
			d.Logger.Errorf("Could not create a signed Deliver SeekInfo message, something is critically wrong: %s", err)
			fetchErrorsC <- &ErrFatal{Message: fmt.Sprintf("could not create a signed Deliver SeekInfo message: %s", err)}
			return
		}

		deliverClient, cancel, err := d.requester.Connect(seekInfoEnv, source)
		if err != nil {
			d.Logger.Warningf("Could not connect to ordering service: %s", err)
			fetchErrorsC <- errors.Wrapf(err, "could not connect to ordering service, orderer-address: %s", source.Address)
			return
		}

		blockRcv := &BlockReceiver{
			channelID:              d.ChannelID,
			blockHandler:           d.BlockHandler,
			updatableBlockVerifier: d.UpdatableBlockVerifier,
			deliverClient:          deliverClient,
			cancelSendFunc:         cancel,
			recvC:                  make(chan *orderer.DeliverResponse),
			stopC:                  make(chan struct{}),
			endpoint:               source,
			logger:                 flogging.MustGetLogger("BlockReceiver").With("orderer-address", source.Address),
		}

		d.mutex.Lock()
		if d.blockReceiver != nil {
			d.blockReceiver.Stop()

View on GitHub (pinned to 2736b63f8f)

Solutions

  1. Check the specific orderer-address shown in the error is running and reachable (ping/nc the host:port).
  2. Refresh endpoints: ensure the peer has up-to-date orderer addresses (endpoint refresh / channel config).
  3. Verify TLS material for that orderer matches (CA certs, SANs); reissue or update crypto config if rotated.
  4. Let the block fetcher retry against other orderers; if all fail, fix shared network/DNS issues.

Example fix

// before: stale orderer address in channel config
// orderer-address: orderer.example.com:7050 (host decommissioned)
// after: update channel config to live orderer
// orderer-address: orderer1.example.com:7050
peer channel update -f updated_orderer_config.pb -c mychannel
Defensive patterns

Strategy: retry

Validate before calling

// validate the endpoint before FetchBlocks attempts Connect
if err := checkOrdererReachable(source.Address); err != nil {
    log.Warnf("skipping source %s: %v", source.Address, err)
    return
}

Try / catch

for err := range fetchErrorsC {
    var wrapped interface{ Unwrap() error } = err
    if strings.Contains(err.Error(), "could not connect to ordering service") {
        log.Warnf("orderer %s connect failed, rotating endpoint: %v", extractAddress(err), err)
        continue // DeliverBlocks retries other sources
    }
    return err
}

Prevention

When it happens

Trigger: During DeliverBlocks -> FetchBlocks for a specific source, Connect fails (dial error, TLS failure, orderer down); the error is wrapped as "could not connect to ordering service, orderer-address: <source.Address>" and sent to fetchErrorsC.

Common situations: An individual orderer in the endpoint list is offline; endpoint address stale after config refresh; TLS cert rotation mismatch; network partition between peer and one orderer while others work.

Related errors


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