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

  1. Call InitFromBuffer or InitFromPath successfully before ValidateCC
  2. Check and handle the error returned by InitFromBuffer/InitFromPath instead of continuing
  3. 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

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


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