hyperledger/fabric · error

expected cc name %s, found %s

Error message

expected cc name %s, found %s

What it means

After unmarshalling, the ChaincodeData.Name embedded in lscc's rwset write must equal the chaincode name in the deployment spec. A mismatch indicates the rwset registers different chaincode data than the spec, so validation fails.

Source

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

			return policyErr(fmt.Errorf("No read write set for lscc was found"))
		}
		// there must be at least one write
		if len(lsccrwset.Writes) < 1 {
			return policyErr(fmt.Errorf("LSCC must issue at least one single putState upon deploy/upgrade"))
		}
		// the first key name must be the chaincode id provided in the deployment spec
		if lsccrwset.Writes[0].Key != cdsArgs.ChaincodeSpec.ChaincodeId.Name {
			return policyErr(fmt.Errorf("expected key %s, found %s", cdsArgs.ChaincodeSpec.ChaincodeId.Name, lsccrwset.Writes[0].Key))
		}
		// the value must be a ChaincodeData struct
		cdRWSet := &ccprovider.ChaincodeData{}
		err = proto.Unmarshal(lsccrwset.Writes[0].Value, cdRWSet)
		if err != nil {
			return policyErr(fmt.Errorf("unmarshalling of ChaincodeData failed, error %s", err))
		}
		// the chaincode name in the lsccwriteset must match the chaincode name in the deployment spec
		if cdRWSet.Name != cdsArgs.ChaincodeSpec.ChaincodeId.Name {
			return policyErr(fmt.Errorf("expected cc name %s, found %s", cdsArgs.ChaincodeSpec.ChaincodeId.Name, cdRWSet.Name))
		}
		// the chaincode version in the lsccwriteset must match the chaincode version in the deployment spec
		if cdRWSet.Version != cdsArgs.ChaincodeSpec.ChaincodeId.Version {
			return policyErr(fmt.Errorf("expected cc version %s, found %s", cdsArgs.ChaincodeSpec.ChaincodeId.Version, cdRWSet.Version))
		}
		// it must only write to 2 namespaces: LSCC's and the cc that we are deploying/upgrading
		for _, ns := range txRWSet.NsRwSets {
			if ns.NameSpace != "lscc" && ns.NameSpace != cdRWSet.Name && len(ns.KvRwSet.Writes) > 0 {
				return policyErr(fmt.Errorf("LSCC invocation is attempting to write to namespace %s", ns.NameSpace))
			}
		}

		logger.Debugf("Validating %s for cc %s version %s", lsccFunc, cdRWSet.Name, cdRWSet.Version)

		switch lsccFunc {
		case lscc.DEPLOY:

			/******************************************************************/

View on GitHub (pinned to 2736b63f8f)

Solutions

  1. Regenerate the deploy/upgrade transaction so the spec and lscc write refer to the same chaincode.
  2. Never reuse or hand-edit endorsed envelopes.
  3. Confirm the chaincodeId in the SDK request matches the deployed chaincode source.
  4. Validate that lscc is the stock implementation writing correct ChaincodeData.
Defensive patterns

Strategy: validation

Validate before calling

if cdRWSet.Name != chaincodeSpec.ChaincodeId.Name {
    return fmt.Errorf("ChaincodeData name %q != spec name %q", cdRWSet.Name, chaincodeSpec.ChaincodeId.Name)
}

Type guard

func chaincodeDataMatchesSpec(cd *ccprovider.ChaincodeData, spec *pb.ChaincodeSpec) bool {
    return cd != nil && cd.Name == spec.ChaincodeId.Name
}

Try / catch

if err := submitTx(envelope); err != nil {
    if strings.Contains(err.Error(), "expected cc name ") {
        // regenerate the deploy/upgrade proposal for the correct chaincode
    }
}

Prevention

When it happens

Trigger: cdRWSet.Name != cdsArgs.ChaincodeSpec.ChaincodeId.Name — lscc wrote ChaincodeData for a different chaincode than the spec claims (tampering, wrong spec, or mixed rwsets).

Common situations: Edited proposal payloads; reusing an old instantiate response for a new chaincode; SDK constructing deploy spec from one cc while lscc simulates another.

Related errors


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