hyperledger/fabric · error
uninitialized package
Error message
uninitialized package
What it means
CDSPackage.ValidateCC validates package contents against ChaincodeData. If the package's depSpec (ChaincodeDeploymentSpec) was never populated — InitFromBuffer/InitFromPath never succeeded — the package is 'uninitialized' and validation cannot proceed, so this error is returned.
Source
Thrown at core/common/ccprovider/cdspackage.go:145
return nil, nil, nil, err
}
hash.Reset()
// compute the id
hash.Write(cdsdata.CodeHash)
hash.Write(cdsdata.MetaDataHash)
id := hash.Sum(nil)
return b, id, cdsdata, nil
}
// ValidateCC returns error if the chaincode is not found or if its not a
// ChaincodeDeploymentSpec
func (ccpack *CDSPackage) ValidateCC(ccdata *ChaincodeData) error {
if ccpack.depSpec == nil {
return errors.New("uninitialized package")
}
if ccpack.data == nil {
return errors.New("nil data")
}
// 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)View on GitHub (pinned to 2736b63f8f)
Solutions
- Call InitFromBuffer or InitFromPath successfully before ValidateCC
- Check and handle the error returned by InitFromBuffer/InitFromPath instead of continuing
- Ensure you are not reusing a CDSPackage that failed initialization in a prior step
Example fix
// before
ccpack := &CDSPackage{}
err := ccpack.ValidateCC(ccdata) // uninitialized
// after
ccpack := &CDSPackage{}
if _, err := ccpack.InitFromBuffer(buf); err != nil { return err }
err = ccpack.ValidateCC(ccdata) Defensive patterns
Strategy: validation
Validate before calling
func initializedPackage(ccpack *ccprovider.CDSPackage, buf []byte) (*ccprovider.CDSPackage, error) {
if _, err := ccpack.InitFromBuffer(buf); err != nil {
return nil, err
}
return ccpack, nil
} Type guard
func hasDepSpec(ccpack *ccprovider.CDSPackage) bool { return ccpack != nil } // plus always init via InitFromBuffer first Try / catch
if _, err := ccpack.InitFromBuffer(buf); err != nil {
return fmt.Errorf("package init failed: %w", err) // never proceed to ValidateCC uninitialized
}
if err := ccpack.ValidateCC(ccdata); err != nil {
return err
} Prevention
- Never construct CDSPackage{} manually and call ValidateCC directly
- Always check the error from InitFromBuffer/InitFromPath before validation
- Use one initialization code path (InitFromBuffer or InitFromPath) consistently
- Reuse the returned ChaincodeData from init instead of building your own
When it happens
Trigger: Calling ValidateCC on a zero-value CDSPackage{}, or on a CDSPackage whose InitFromBuffer/InitFromPath call failed earlier and whose error was ignored.
Common situations: Code constructing CDSPackage manually without initialization; ignoring the error from InitFromBuffer and continuing; test setups (TestValidateCCErrorPaths) exercising the error path.
Related errors
- illegal file name in payload: %s
- cannot collect files from empty chaincode path
- invalid chaincode ID
- inconsistent ccid info (%s/%s)
- invalid chaincode deployment spec
AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04).
Data as JSON: /api/errors/2185963c4f7a140f.
Report an issue: GitHub.