hyperledger/fabric · error

uninitialized package

Error message

uninitialized package

What it means

SignedCDSPackage.ValidateCC (used by GetCCPackage to identify an uploaded package) returns 'uninitialized package' when the internal signed deployment spec (sDepSpec) has never been populated, i.e. InitFromBuffer/InitFromDependencySpec was never successfully called. It distinguishes 'never initialized' from 'initialized but invalid content'.

Source

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

	}

	hash.Reset()

	// compute the id
	hash.Write(scdsdata.CodeHash)
	hash.Write(scdsdata.MetaDataHash)
	hash.Write(scdsdata.SignatureHash)

	id := hash.Sum(nil)

	return b, id, scdsdata, nil
}

// ValidateCC returns error if the chaincode is not found or if its not a
// ChaincodeDeploymentSpec
func (ccpack *SignedCDSPackage) ValidateCC(ccdata *ChaincodeData) error {
	if ccpack.sDepSpec == nil {
		return errors.New("uninitialized package")
	}

	if ccpack.sDepSpec.ChaincodeDeploymentSpec == nil {
		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)

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Call InitFromBuffer (or InitFromDependencySpec) on the SignedCDSPackage and check its error before invoking ValidateCC.
2. If a prior InitFromBuffer failed, fix that underlying error first (bad bytes, BCCSP init failure, nil policy) — ValidateCC will then work.
3. Ensure the right package type is used: validating a plain CDSPackage payload as a SignedCDSPackage will appear as uninitialized.
4. In tests, build the package through the normal init path rather than instantiating the struct bare.

Example fix

// before
pack := &ccprovider.SignedCDSPackage{}
err = pack.ValidateCC(ccdata)
// after
pack := &ccprovider.SignedCDSPackage{}
if err := pack.InitFromBuffer(buf, hasher); err != nil {
    return err
}
err = pack.ValidateCC(pack.GetChaincodeData())

pack := &ccprovider.SignedCDSPackage{}
if err := pack.InitFromBuffer(buf, hasher); err != nil {
    return fmt.Errorf("package init failed: %w", err)
}

if err := pack.ValidateCC(ccdata); err != nil {
    if err.Error() == "uninitialized package" {
        // re-run InitFromBuffer/InitFromDependencySpec with the raw bytes
    }
    return err
}

When it happens

Trigger: Calling ValidateCC (directly or via GetCCPackage) on a fresh &SignedCDSPackage{} with no prior successful InitFromBuffer/InitFromDependencySpec; a previous InitFromBuffer failed partway leaving sDepSpec nil.

Common situations: A package loader that created the wrapper but skipped initialization; an error from an earlier InitFromBuffer swallowed or ignored; unit tests constructing the struct directly and validating immediately.

Related errors

• instantiation policy cannot be nil for chaincode (%s:%s)
• signed chaincode deployment spec cannot be nil in a package
• only applicable for private data
• unknown operation type
• error reading chaincode install package at %s

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