current config has consortiums section, but new config does

Error message

current config has consortiums section, but new config does not

What it means

Thrown by ValidateNew when the current config has a Consortiums section (i.e. it is a system channel or otherwise defines consortiums) but the proposed new config does not. The Consortiums group cannot be removed via a config update; doing so would break the definitions of channels that can be created from those consortiums. (Note: this is errors.Errorf used where errors.New would suffice — the message is constant.)

Source

Thrown at common/channelconfig/bundle.go:140

			return errors.New("current config has application section, but new config does not")
		}

		for orgName, org := range ac.Organizations() {
			norg, ok := nac.Organizations()[orgName]
			if !ok {
				continue
			}
			mspID := org.MSPID()
			if mspID != norg.MSPID() {
				return errors.Errorf("application org %s attempted to change MSP ID from %s to %s", orgName, mspID, norg.MSPID())
			}
		}
	}

	if cc, ok := b.ConsortiumsConfig(); ok {
		ncc, ok := nb.ConsortiumsConfig()
		if !ok {
			return errors.Errorf("current config has consortiums section, but new config does not")
		}

		for consortiumName, consortium := range cc.Consortiums() {
			nconsortium, ok := ncc.Consortiums()[consortiumName]
			if !ok {
				continue
			}

			for orgName, org := range consortium.Organizations() {
				norg, ok := nconsortium.Organizations()[orgName]
				if !ok {
					continue
				}
				mspID := org.MSPID()
				if mspID != norg.MSPID() {
					return errors.Errorf("consortium %s org %s attempted to change MSP ID from %s to %s", consortiumName, orgName, mspID, norg.MSPID())
				}
			}

View on GitHub (pinned to 2736b63f8f)

Solutions

Retain the groups->Consortiums group from the current config in the proposed config; only mutate values within it.
Regenerate the update payload by diffing two full JSON configs (current and edited) via configtxlator so no top-level groups are silently dropped.
If consortiums must be removed, that is part of a deliberate system-channel removal/migration path (Fabric 3 removed system channels), not a plain config update.
Inspect the update transaction with configtxlator to confirm Consortiums is present before submitting.

Defensive patterns

Strategy: validation

Validate before calling

// Ensure a system-channel-style update keeps the Consortiums group
func requireConsortiumsGroup(current, proposed *cb.Config) error {
	if _, ok := current.Groups["Consortiums"]; ok {
		if _, ok := proposed.Groups["Consortiums"]; !ok {
			return errors.New("proposed config drops the Consortiums group")
		}
	}
	return nil
}

Try / catch

if err := configtxManager.ProposeConfigUpdate(env); err != nil {
	if strings.Contains(err.Error(), "consortiums section") {
		// rebuild the update from the current system channel config, keeping Consortiums
		return fmt.Errorf("structural config error: %w", err)
	}
	return err
}

Prevention

Generate system channel updates only from a decoded copy of the current system channel config
Keep all top-level groups (Orderer, Consortiums) intact when editing; change values, not structure
Use configtxlator compute-update so only intended deltas enter the transaction
When planning system-channel removal (Fabric 3 migration), follow the documented migration path instead of dropping groups via update

When it happens

Trigger: A config update against a system channel (or any channel whose config contains groups->Consortiums) where the Consortiums group was deleted from the proposed config, e.g. a configtxlator-edited update that removed groups->Consortiums.

Common situations: Migrating/templating configs between a system channel and application channels and applying the wrong shape; editing a system channel config to drop consortiums; automated tooling that rebuilds the config tree and omits the Consortiums group.

Related errors

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