hyperledger/fabric · error

inconsistent ccid info (%s/%s)

Error message

inconsistent ccid info (%s/%s)

What it means

The chaincode name in the header extension (ccID) differs from the chaincode name reported in the chaincode action's response payload (respPayload.ChaincodeId.Name). VSCC rejects the transaction as TxValidationCode_INVALID_OTHER_REASON because this inconsistency indicates a forged or mismatched endorsement result.

Source

Thrown at core/committer/txvalidator/v14/vscc_validator.go:106

		return peer.TxValidationCode_INVALID_OTHER_REASON, errors.New("nil ChaincodeId in header extension")
	}

	if respPayload.ChaincodeId == nil {
		return peer.TxValidationCode_INVALID_OTHER_REASON, errors.New("nil ChaincodeId in ChaincodeAction")
	}

	// get name and version of the cc we invoked
	ccID := hdrExt.ChaincodeId.Name
	ccVer := respPayload.ChaincodeId.Version

	// sanity check on ccID
	if ccID == "" {
		err = errors.New("invalid chaincode ID")
		logger.Errorf("%+v", err)
		return peer.TxValidationCode_INVALID_OTHER_REASON, err
	}
	if ccID != respPayload.ChaincodeId.Name {
		err = errors.Errorf("inconsistent ccid info (%s/%s)", ccID, respPayload.ChaincodeId.Name)
		logger.Errorf("%+v", err)
		return peer.TxValidationCode_INVALID_OTHER_REASON, err
	}
	// sanity check on ccver
	if ccVer == "" {
		err = errors.New("invalid chaincode version")
		logger.Errorf("%+v", err)
		return peer.TxValidationCode_INVALID_OTHER_REASON, err
	}

	var wrNamespace []string
	alwaysEnforceOriginalNamespace := v.cr.Capabilities().V1_2Validation()
	if alwaysEnforceOriginalNamespace {
		wrNamespace = append(wrNamespace, ccID)
		if respPayload.Events != nil {
			ccEvent := &peer.ChaincodeEvent{}
			if err = proto.Unmarshal(respPayload.Events, ccEvent); err != nil {
				return peer.TxValidationCode_INVALID_OTHER_REASON, errors.Wrapf(err, "invalid chaincode event")

View on GitHub (pinned to 2736b63f8f)

Solutions

1. Rebuild the transaction with the SDK so header extension and endorsement responses come from the same proposal/invocation.
2. Stop caching/reusing proposal payloads or headers across different chaincode invocations.
3. If seen unexpectedly on network, investigate the submitting client(s) or potential payload tampering.

Example fix

// before: reusing old hdrExt for new response
hdrExt := oldHeaderExtension
respPayload := buildActionFor("othercc")
// after: build envelope from a single proposal flow
transaction, _ := channel.CreateTransaction(responsesFromSameProposal)

if hdrExt.ChaincodeId.Name != respPayload.ChaincodeId.Name {
    return fmt.Errorf("header chaincode %q does not match action chaincode %q; rebuild the transaction", hdrExt.ChaincodeId.Name, respPayload.ChaincodeId.Name)
}

func consistentChaincodeIds(hdrExt *peer.ChaincodeHeaderExtension, action *peer.ChaincodeAction) bool {
	return hdrExt != nil && hdrExt.ChaincodeId != nil &&
		action != nil && action.ChaincodeId != nil &&
		hdrExt.ChaincodeId.Name == action.ChaincodeId.Name
}

if ccID != respPayload.ChaincodeId.Name {
    logger.Warnf("tx rejected: inconsistent ccid info (%s/%s)", ccID, respPayload.ChaincodeId.Name)
    return peer.TxValidationCode_INVALID_OTHER_REASON, nil
}

When it happens

Trigger: A transaction whose header extension names chaincode A while the endorsed ChaincodeAction says chaincode B — produced by clients reusing headers across invokes, mixing endorsement responses, or maliciously swapping payloads.

Common situations: Client bug reusing a cached proposal/header for a different chaincode; manual stitching of proposal responses from different invocations; tampering attempts blocked by validation.

Related errors

• error unmarshalling ChaincodeHeaderExtension
• nil ChaincodeId in header extension
• nil ChaincodeId in ChaincodeAction
• invalid chaincode ID
• invalid chaincode version

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