hyperledger/fabric · error

unknown collection configuration type

Error message

unknown collection configuration type

What it means

When validating collection updates in an upgrade rwset, each CollectionConfig must contain a StaticCollectionConfig payload. If the oneof payload resolves to nil (unknown/unset config type), the transaction is rejected because only static collections are supported.

Source

Thrown at core/handlers/validation/builtin/v13/lscc_validation_logic.go:66

		Data:      env.Payload,
		Identity:  shdr.Creator,
		Signature: env.Signature,
	}}
	err = vscc.policyEvaluator.Evaluate(instantiationPolicy, sd)
	if err != nil {
		return policyErr(fmt.Errorf("chaincode instantiation policy violated, error %s", err))
	}
	return nil
}

func validateNewCollectionConfigs(newCollectionConfigs []*pb.CollectionConfig) error {
	newCollectionsMap := make(map[string]bool, len(newCollectionConfigs))
	// Process each collection config from a set of collection configs
	for _, newCollectionConfig := range newCollectionConfigs {

		newCollection := newCollectionConfig.GetStaticCollectionConfig()
		if newCollection == nil {
			return errors.New("unknown collection configuration type")
		}

		// Ensure that there are no duplicate collection names
		collectionName := newCollection.GetName()

		if err := validateCollectionName(collectionName); err != nil {
			return err
		}

		if _, ok := newCollectionsMap[collectionName]; !ok {
			newCollectionsMap[collectionName] = true
		} else {
			return fmt.Errorf("collection-name: %s -- found duplicate collection configuration", collectionName)
		}

		// Validate gossip related parameters present in the collection config
		maximumPeerCount := newCollection.GetMaximumPeerCount()
		requiredPeerCount := newCollection.GetRequiredPeerCount()

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Regenerate the collection configuration so each entry is a proper StaticCollectionConfig inside CollectionConfig
2. Use the peer's collection config format (collections-config JSON) with the standard CLI/SDK
3. Ensure the SDK/proto versions match the peer's Fabric release

Example fix

// before
collection config entry missing "type" payload / malformed oneof
// after
{"name":"col1","policy":"OR('Org1MSP.member')","requiredPeerCount":1,"maxPeerCount":2,"blockToLive":0}
peer chaincode upgrade ... --collections-config collections.json

for (const c of collectionUpdates) {
  if (!c.staticCollectionConfig || !c.staticCollectionConfig.name) {
    throw new Error('CollectionConfig must contain a StaticCollectionConfig payload');
  }
}

function isStaticCollection(c) {
  return c != null && typeof c === 'object' && 'staticCollectionConfig' in c && c.staticCollectionConfig !== null;
}

try {
  await upgradeContract.submitTransaction(..., collectionJson);
} catch (e) {
  if (String(e).includes('unknown collection configuration type')) {
    // fix collections-config JSON and resubmit
  }
}

When it happens

Trigger: An lscc UPGRADE whose rwset collection updates include a CollectionConfig whose inner message is not a StaticCollectionConfig (e.g. unset or a future/unknown type).

Common situations: SDKs or tools writing collection config protobufs without setting the static payload; protobuf version mismatches dropping the payload; hand-edited collections.json assembled into the wrong wrapper type.

Related errors

• tx creator does not have read access permission on privateda
• tx creator does not have write access permission on privated
• collection configuration is empty
• no collection config for chaincode %#v
• unable to check whether collection existed earlier for chain

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