What causes "request is for channel %s but expected channel %s" in hyperledger/fabric?

Point the client's broadcast at the correct channel for the envelope

request is for channel %s but expected channel %s

Error message

request is for channel %s but expected channel %s

What it means

verifyRequest checks that the request's channel header ChannelId matches the verifier's channel. A mismatch means the envelope was delivered to the wrong channel's request stream and is rejected with the observed vs expected channel names.

Source

Thrown at orderer/consensus/smartbft/verifier.go:179

func (v *Verifier) verifyRequest(rawRequest []byte, noConfigAllowed bool) (types.RequestInfo, error) {
	req, err := v.ReqInspector.unwrapReq(rawRequest)
	if err != nil {
		return types.RequestInfo{}, err
	}

	err = v.AccessController.Evaluate([]*protoutil.SignedData{
		{Identity: req.sigHdr.Creator, Data: req.envelope.Payload, Signature: req.envelope.Signature},
	})
	if err != nil {
		return types.RequestInfo{}, errors.Wrap(err, "access denied")
	}

	if noConfigAllowed && req.chHdr.Type != int32(cb.HeaderType_ENDORSER_TRANSACTION) {
		return types.RequestInfo{}, errors.Errorf("only endorser transactions can be sent with other transactions")
	}

	if req.chHdr.ChannelId != v.Channel {
		return types.RequestInfo{}, errors.Errorf("request is for channel %s but expected channel %s", req.chHdr.ChannelId, v.Channel)
	}

	switch req.chHdr.Type {
	case int32(cb.HeaderType_CONFIG):
	case int32(cb.HeaderType_ORDERER_TRANSACTION):
		return types.RequestInfo{}, fmt.Errorf("orderer transactions are not supported in v3")
	case int32(cb.HeaderType_ENDORSER_TRANSACTION):
	default:
		return types.RequestInfo{}, errors.Errorf("transaction of type %s is not allowed to be included in blocks", cb.HeaderType_name[req.chHdr.Type])
	}

	if req.chHdr.Type == int32(cb.HeaderType_CONFIG) {
		err = v.ConfigValidator.ValidateConfig(req.envelope)
		if err != nil {
			v.Logger.Errorf("Error verifying config update: %v", err)
			return types.RequestInfo{}, err
		}

View on GitHub (pinned to 2736b63f8f)

Solutions

Point the client's broadcast at the correct channel for the envelope
Re-create the envelope with the intended ChannelId in its channel header
Fix routing/proxy configuration so envelopes reach the matching channel's orderer service

Defensive patterns

Strategy: validation

Validate before calling

if req.chHdr.ChannelId != expectedChannel {
    return fmt.Errorf("envelope for %s cannot be sent to %s", req.chHdr.ChannelId, expectedChannel)
}

Type guard

func envelopeMatchesChannel(hdr *common.ChannelHeader, ch string) bool {
    return hdr.ChannelId == ch
}

Try / catch

if _, err := VerifyRequest(req); err != nil {
    if strings.Contains(err.Error(), "but expected channel") {
        // fix client routing / re-target broadcast
    }
}

Prevention

Double-check channel names in client configuration
Verify envelope headers before broadcast
Use per-channel endpoints in SDK/proxy config

When it happens

Trigger: A client broadcasting an envelope signed for channel A to the orderer node serving channel B; misconfigured broadcast endpoints in multi-channel networks.

Common situations: SDK/envoy routing envelopes to the wrong channel; copy-paste of channel names in tooling; a node joined to multiple channels receiving fan-out traffic on the wrong stream.

Related errors

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