hyperledger/fabric · error

invalid chaincode data %v (%v)

Error message

invalid chaincode data %v (%v)

What it means

ValidateCC compares the name/version in the ChaincodeData against the name/version in the inner ChaincodeDeploymentSpec's ChaincodeId. A mismatch means the metadata and the deployment spec inside the package disagree, so the package is internally inconsistent.

Source

Thrown at core/common/ccprovider/sigcdspackage.go:206

		return errors.New("signed chaincode deployment spec cannot be nil in a package")
	}

	if ccpack.depSpec == nil {
		return errors.New("chaincode deployment spec cannot be nil in a package")
	}

	// This is a hack. LSCC expects a specific LSCC error when names are invalid so it
	// has its own validation code. We can't use that error because of import cycles.
	// Unfortunately, we also need to check if what have makes some sort of sense as
	// protobuf will gladly deserialize garbage and there are paths where we assume that
	// a successful unmarshal means everything works but, if it fails, we try to unmarshal
	// into something different.
	if !isPrintable(ccdata.Name) {
		return fmt.Errorf("invalid chaincode name: %q", ccdata.Name)
	}

	if ccdata.Name != ccpack.depSpec.ChaincodeSpec.ChaincodeId.Name || ccdata.Version != ccpack.depSpec.ChaincodeSpec.ChaincodeId.Version {
		return fmt.Errorf("invalid chaincode data %v (%v)", ccdata, ccpack.depSpec.ChaincodeSpec.ChaincodeId)
	}

	otherdata := &SignedCDSData{}
	err := proto.Unmarshal(ccdata.Data, otherdata)
	if err != nil {
		return err
	}

	if !proto.Equal(ccpack.data, otherdata) {
		return errors.New("data mismatch")
	}

	return nil
}

// InitFromBuffer sets the buffer if valid and returns ChaincodeData
func (ccpack *SignedCDSPackage) InitFromBuffer(buf []byte) (*ChaincodeData, error) {
	env := &common.Envelope{}

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Rebuild the package so name and version match across ChaincodeData and ChaincodeDeploymentSpec
2. Use `peer chaincode package` / `peer chaincode signpackage` instead of hand-assembling packages
3. Ensure the install and upgrade flows use the same version string everywhere

Example fix

// before
ccdata.Version = "v2"; depSpec.ChaincodeSpec.ChaincodeId.Version = "v1" // mismatch
// after
ccdata.Version = "v1"; depSpec.ChaincodeSpec.ChaincodeId.Version = "v1"

func consistentNameVersion(c *pb.ChaincodeData, cds *pb.ChaincodeDeploymentSpec) bool {
    return c.Name == cds.ChaincodeSpec.ChaincodeId.Name &&
        c.Version == cds.ChaincodeSpec.ChaincodeId.Version
}

func matchesSpec(c *pb.ChaincodeData, cds *pb.ChaincodeDeploymentSpec) bool {
    return c != nil && cds != nil && consistentNameVersion(c, cds)
}

cd, err := GetCCPackage(buf, idFunc)
if err != nil {
    if strings.Contains(err.Error(), "invalid chaincode data") {
        return fmt.Errorf("package metadata/spec mismatch; rebuild with peer chaincode package: %w", err)
    }
    return err
}

When it happens

Trigger: GetCCPackage -> ValidateCC on a package where ccdata.Name/Version differ from ccpack.depSpec.ChaincodeSpec.ChaincodeId.Name/Version, e.g. after editing one of them or mixing package parts.

Common situations: Manually editing the chaincode name or version in package metadata; combining a CDS from one package with metadata from another; upgrading chaincode but only updating part of the package.

Related errors

• chaincode deployment spec cannot be nil in a package
• invalid chaincode name: %q
• only applicable for private data
• unknown operation type
• unsupported policy type %T on channel '%s'

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