hyperledger/fabric · error

unknown collection configuration type

Error message

unknown collection configuration type

What it means

When validating a collection configuration upgrade, validateNewCollectionConfigs extracts each CollectionConfig's StaticCollectionConfig. If GetStaticCollectionConfig() returns nil, the entry is of an unknown/unrecognized collection configuration type and the whole collection upgrade is rejected.

Source

Thrown at core/handlers/validation/builtin/v12/validation_logic.go:209

		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. Ensure every entry in the CollectionConfigPackage contains a StaticCollectionConfig (correctly set the oneof payload)
  2. Regenerate the collections configuration using the peer CLI (peer chaincode upgrade -collections-config) instead of hand-crafting protos
  3. Align peer and SDK/tool versions so the collection config types match the supported schema

Example fix

// before
cfg := &pb.CollectionConfig{} // no payload set -> StaticCollectionConfig nil
configs = append(configs, cfg)
// after
cfg := &pb.CollectionConfig{Payload: &pb.CollectionConfig_StaticCollectionConfig{
    StaticCollectionConfig: &pb.StaticCollectionConfig{Name: "col1", ...}}}
configs = append(configs, cfg)
Defensive patterns

Strategy: validation

Validate before calling

for _, cfg := range collectionConfigPackage.Config {
    if cfg.GetStaticCollectionConfig() == nil {
        return errors.New("collection config entry missing StaticCollectionConfig payload")
    }
}

Type guard

func isStatic(cfg *pb.CollectionConfig) bool {
    return cfg != nil && cfg.GetStaticCollectionConfig() != nil
}

Prevention

When it happens

Trigger: A collection config package in a chaincode upgrade whose CollectionConfig payload is not a StaticCollectionConfig (nil static config), typically due to a malformed or future-version protobuf message being submitted in the collections upgrade set.

Common situations: Hand-edited or tool-generated collections_config.json/proto that wraps nothing or an unsupported type; submitting collections config produced by a newer Fabric version with an unrecognized collection type to an older peer; corrupted chaincode upgrade package.

Related errors


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