Existing version of the cc on the ledger (%s) should be diff

Error message

Existing version of the cc on the ledger (%s) should be different from the upgraded one

What it means

On upgrade, the version recorded on the ledger must differ from the version in the upgrade proposal. Fabric requires an actual version change (e.g. 1.0 -> 1.1); re-submitting an upgrade with the same version as the currently instantiated chaincode is rejected to make upgrades meaningful and idempotency-detectable.

Source

Thrown at core/handlers/validation/builtin/v13/lscc_validation_logic.go:545

			// CONS: this would be a point of non-determinism
			err := vscc.checkInstantiationPolicy(chid, env, pol, payl)
			if err != nil {
				return err
			}

		case lscc.UPGRADE:
			/**************************************************************/
			/* security check 1 - cc in the LCCC table of instantiated cc */
			/**************************************************************/
			if !ccExistsOnLedger {
				return policyErr(fmt.Errorf("Upgrading non-existent chaincode %s", cdsArgs.ChaincodeSpec.ChaincodeId.Name))
			}

			/**********************************************************/
			/* security check 2 - existing cc's version was different */
			/**********************************************************/
			if cdLedger.Version == cdsArgs.ChaincodeSpec.ChaincodeId.Version {
				return policyErr(fmt.Errorf("Existing version of the cc on the ledger (%s) should be different from the upgraded one", cdsArgs.ChaincodeSpec.ChaincodeId.Version))
			}

			/****************************************************************************/
			/* security check 3 validation of rwset (and of collections if enabled) */
			/****************************************************************************/
			// Only in v1.2, a collection can be updated during a chaincode upgrade
			if ac.V1_2Validation() {
				// do extra validation for collections
				err := vscc.validateRWSetAndCollection(lsccrwset, cdRWSet, lsccArgs, lsccFunc, ac, chid)
				if err != nil {
					return err
				}
			} else {
				// there can only be a single ledger write
				if len(lsccrwset.Writes) != 1 {
					return policyErr(fmt.Errorf("LSCC can only issue a single putState upon upgrade"))
				}
			}

View on GitHub (pinned to 2736b63f8f)

Solutions

Bump the chaincode version in the upgrade proposal (e.g. from 1.0 to 1.1) and rebuild/reinstall the package.
Query the currently instantiated version first and submit the upgrade with a strictly different version.
Stop re-submitting an already-committed upgrade transaction; check the txid status instead.
Parameterize version in deployment scripts instead of hard-coding it.

Example fix

// before
version = "1.0" // same as ledger
// after
version = "1.1" // must differ from the instantiated version

Defensive patterns

Strategy: validation

Validate before calling

// ensure the new version differs from the ledger version
ledgerCd := lsccClient.Query("getccdata", []string{"mycc"})
if cds.ChaincodeSpec.ChaincodeId.Version == ledgerCd.Version {
    return errors.New("upgrade version must differ from " + ledgerCd.Version)
}

Type guard

func isUpgradeVersion(current, proposed string) bool { return proposed != "" && proposed != current }

Try / catch

if err != nil && strings.Contains(err.Error(), "should be different from the upgraded one") { /* bump the version and resubmit the upgrade */ }

Prevention

Always increment the version when upgrading
Read the current version from lscc before building the proposal
Avoid replaying committed upgrade transactions; check txid status

When it happens

Trigger: An lscc upgrade transaction whose ChaincodeSpec.ChaincodeId.Version equals cdLedger.Version — re-running the same upgrade, or a script that forgets to bump the version.

Common situations: Replayed upgrade proposals after a successful upgrade, CI scripts with hard-coded versions, developers forgetting to bump the version in the deployment spec after code changes, attempting to 're-upgrade' to force re-initialization without a version bump.

Related errors

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