hyperledger/fabric · error

transaction is aimed at channel %s but our channel is %s

Error message

transaction is aimed at channel %s but our channel is %s

What it means

The channel ID extracted from the config update does not match the channel this SmartBFT validator is validating (cbv.ValidatingChannel). A config transaction for one channel must never be applied to another, so it is rejected with both IDs in the message.

Source

Thrown at orderer/consensus/smartbft/configverifier.go:225

	}

	typ := common.HeaderType(chdr.Type)

	cbv.Logger.Infof("Applying filters for config update of type %s to channel %s", typ, chdr.ChannelId)

	// First apply the filters on the outer envelope, regardless of the type of transaction it is.
	if err := cbv.Filters.ApplyFilters(chdr.ChannelId, outEnv); err != nil {
		return err
	}

	var expectedConfigEnv *common.ConfigEnvelope
	channelID, err := protoutil.ChannelID(confEnv.LastUpdate)
	if err != nil {
		return errors.Errorf("error extracting channel ID from config update")
	}

	if cbv.ValidatingChannel != channelID {
		return errors.Errorf("transaction is aimed at channel %s but our channel is %s", channelID, cbv.ValidatingChannel)
	} else {
		expectedConfigEnv, err = cbv.ConfigUpdateProposer.ProposeConfigUpdate(chdr.ChannelId, confEnv.LastUpdate)
		if err != nil {
			cbv.Logger.Errorf("Rejecting config proposal due to %v", err)
			return err
		}
	}

	if err := cbv.checkConsentersMatchPolicy(confEnv.Config); err != nil {
		return err
	}

	// Extract the Config from the result of ProposeConfigUpdate, and compare it
	// with the pending config.
	if proto.Equal(confEnv.Config, expectedConfigEnv.Config) {
		return nil
	}
	cbv.Logger.Errorf("Pending Config is %v, but it should be %v", confEnv.Config, expectedConfigEnv.Config)

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Regenerate the config update envelope for the correct channel so ChannelHeader.ChannelId equals the target channel
2. Submit the envelope to the correct channel's ordering endpoint
3. Double-check any scripted workflows that copy envelopes across channels

Example fix

// before
chdr := &common.ChannelHeader{ChannelId: "channel-a"} // submitted to channel-b
// after
chdr := &common.ChannelHeader{ChannelId: "channel-b"} // matches target channel

if channelID != validatingChannel {
    return fmt.Errorf("refusing to submit: update targets %s, expected %s", channelID, validatingChannel)
}

When it happens

Trigger: verifyConfigUpdateMsg compares channelID (from the inner envelope) against cbv.ValidatingChannel and they differ — e.g. the update envelope was broadcast to the wrong channel's ordering service.

Common situations: Reusing a config update envelope built for another channel; copy-paste of envelope bytes between channel tests; multi-channel deployments where the client targets the wrong channel in the submit call.

Related errors

• invalid BFT metadata configuration
• unexpected envelope type %s
• empty Config
• empty channel group
• no groups in channel group

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