checkcommitreadiness return always false for approvals

[gianfabiopezzolla]

Hi there, I'm trying to setup chaincode on fabric 2.2, but, I dont'know why, approvals are always setted to false when I run peer lifecycle chaincode checkcommitreadiness:

this is my approveformyorg:

peer lifecycle chaincode approveformyorg -o orderer.example.com:7050 --cafile $ORDERER_CA --channelID mychannel --name newc --version 1.0 --init-required --package-id $CONTRACTS_PACKAGE_ID --sequence 1 --signature-policy 'OR("Org1MSP.peer", "Org2MSP.peer")' --collections-config /opt/gopath/src/github.com/chaincode/collections/collections_config.json

and its output:

txid [376e4c1d55d4cffa08e4d6f3f9032ae21f54e6fd78f8ac1e406037988143b4a9] committed with status (VALID) at peer0.contracts.example.com:7051

this is my checkcommitreadiness:

peer lifecycle chaincode checkcommitreadiness -o orderer.example.com:7050 --cafile $ORDERER_CA --channelID mychannel --name newc --version 1.0 --init-required --sequence 1 --output json --signature-policy 'OR("Org1MSP.peer", "Org2MSP.peer")' --collections-config /opt/gopath/src/github.com/chaincode/collections/collections_config.json

when I run the above command the output is always:

{
        "approvals": {
                "Org2MSP": false,
                "Customer": false,
                "Org1MSP": false
        }
}

why?

Any suggestion is welcome. Thanks in advance

[ricardo-cavalheiro]

I'm facing the same issue. It looks like that running peer lifecycle chaincode approveformyorg without the --init-required flag works just fine. Maybe it's a legacy API? I mean, for versions lower than 2.x?

[denyeart]

I'm not able to reproduce, it works for me.

--init-required must either be absent or present in both the approveformyorg and checkcommitreadiness calls. In the example above it is present in both, so it should return true.

[Jayrald07]

Are there any updates regarding this issue? I both used removed and added --init-required flag, but still returning false for all of my organizations. It only works when I removed the --collections-config flag. I think this is related to updating the chaincode definition with collections config.

[zRich]

I'm facing the same issue and cannot commit it

[Koosha-E-Khorasani]

The same here, but I could commit. It is very strange. I put screenshot of my checkcommitreadiness and chaincode querycommitted(peer version 2.5.4):

[satota2]

@Koosha-E-Khorasani In order to further investigate this issue, could you provide the series of chaincode lifecycle commands you executed? Specifically, I'd like to see the commands for approveformyorg, checkcommitreadiness, and querycommitted, along with the flags you used for each. This information will be invaluable for reproducing the situation and identifying the cause.

[Koosha-E-Khorasani]

@satota2 sorry for the delay! I followed this for the chaincode installation.

• installing chain code: peer lifecycle chaincode install basic.tar.gz

• approve

peer lifecycle chaincode approveformyorg -o host.docker.internal:7041 --ordererTLSHostnameOverride host.docker.internal --channelID channel1 --name basic --version 1.0 --package-id $CC_PACKAGE_ID --sequence 1 --tls --cafile ../org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem

• commit readiness

peer lifecycle chaincode commit -o host.docker.internal:7041 --ordererTLSHostnameOverride host.docker.internal --channelID channel1 --name basic --version 1.0 --sequence 1 --tls --cafile ../org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem --peerAddresses host.docker.internal:7061 --tlsRootCertFiles ../org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem --peerAddresses host.docker.internal:7071 --tlsRootCertFiles ../org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem

• querycommited

peer lifecycle chaincode querycommitted --channelID channel1 --name basic --cafile ../org1/peer1/tls-msp/tlscacerts/tls-0-0-0-0-7052.pem

[satota2]

@Koosha-E-Khorasani Thank you for sharing the information.

Upon reviewing the commands you've shared, I noticed that the value for the chaincode name (--name) in approveformyorg seems to be different from what is used in other commands; it's basic_1.0. It's important to maintain consistency in the chaincode definition parameters specified in approveformyorg, commitreadiness, and commit.

Would the issue be resolved if we change the name value in approveformyorg to basic?

[Koosha-E-Khorasani]

@satota2 Thank you for mentioning that. Different chaincode name here is a typo , when I faced the probelm I had used the right chaincode name (as you can see in the screenshots above, they all belong to basic chaincode). I edited my previous comment.

Thus, the problem does not resolve when you use chaincode name 'basic' in all of commands.

[satota2]

@Koosha-E-Khorasani Thank you for your information. I tried this instruction on my local environment but I'm not able to reproduce the problem.

To get a more detailed understanding of the situation, you can execute the following commands: Switch to Org1, then run: peer lifecycle chaincode queryapproved --channelID channel1 --name basic --output json

Switch to Org2, then run: peer lifecycle chaincode queryapproved --channelID channel1 --name basic --output json

By running these commands, you should be able to obtain the latest approved chaincode definition for each organization. This can be useful for troubleshooting. The output will look something like this:

{
        "sequence": 2,
        "version": "2.0",
        "endorsement_plugin": "escc",
        "validation_plugin": "vscc",
        "validation_parameter": "EiAvQ2hhbm5lbC9BcHBsaWNhdGlvbi9FbmRvcnNlbWVudA==",
        "collections": {},
        "source": {
                "Type": {
                        "LocalPackage": {
                                "package_id": "basic_2.0:30934b6d6e068f10ae0257713bba946cad2352d0e3f75513d203e6ae066d82e1"
                        }
                }
        }
}

[dc-atos-dev]

I am having the same issue, what's the solution??

[denyeart]

@dc-atos-dev and anybody else hitting the issue... please post the approved chaincode definition known to each org as suggested above at https://github.com/hyperledger/fabric/issues/3330#issuecomment-1705106470.

The approved chaincode definitions can then be evaluated to determine if there is a difference between the orgs.

Reminder, to switch between orgs you can use environment variables as mentioned in tutorial at https://hyperledger-fabric.readthedocs.io/en/latest/deploy_chaincode.html, e.g.:

export CORE_PEER_LOCALMSPID="Org2MSP"
export CORE_PEER_TLS_ROOTCERT_FILE=${PWD}/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
export CORE_PEER_MSPCONFIGPATH=${PWD}/organizations/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp
export CORE_PEER_ADDRESS=localhost:9051

[dc-atos-dev]

Hi @denyeart

This is the ouput for ORG1: ariuserbip@bippreproductionservices:~/fabric$ docker exec cli peer lifecycle chaincode queryapproved --channelID mychannel --name vdr --output json { "sequence": 1, "version": "1.0", "endorsement_plugin": "escc", "validation_plugin": "vscc", "validation_parameter": "CiwSDBIKCAESAggAEgIIARoNEgsKB09yZzFNU1AQAxoNEgsKB09yZzJNU1AQAw==", "collections": { "config": [ { "Payload": { "StaticCollectionConfig": { "name": "didDocCollection", "member_orgs_policy": { "Payload": { "SignaturePolicy": { "rule": { "Type": { "NOutOf": { "n": 1, "rules": [ { "Type": { "SignedBy": 0 } }, { "Type": { "SignedBy": 1 } } ] } } }, "identities": [ { "principal": "CgdPcmcxTVNQ" }, { "principal": "CgdPcmcyTVNQ" } ] } } }, "maximum_peer_count": 1, "member_only_read": true, "member_only_write": true, "endorsement_policy": { "Type": { "SignaturePolicy": { "rule": { "Type": { "NOutOf": { "n": 1, "rules": [ { "Type": { "SignedBy": 0 } }, { "Type": { "SignedBy": 1 } } ] } } }, "identities": [ { "principal": "CgdPcmcxTVNQ" }, { "principal": "CgdPcmcyTVNQ" } ] } } } } } } ] }, "init_required": true, "source": { "Type": { "LocalPackage": { "package_id": "vdr:298182c83facca0e4613aa1e31824cb642a6a5a5aa3f99d8ee39bc502376129f" } } } }

Org2:

ariuserbip@bippreproductionservices:~/fabric$ docker exec -e CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp -e CORE_PEER_ADDRESS=peer0.org2.example.com:9051 -e CORE_PEER_LOCALMSPID="Org2MSP" -e CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt cli peer lifecycle chaincode queryapproved --channelID mychannel --name vdr --output json { "sequence": 1, "version": "1.0", "endorsement_plugin": "escc", "validation_plugin": "vscc", "validation_parameter": "CiwSDBIKCAESAggAEgIIARoNEgsKB09yZzFNU1AQAxoNEgsKB09yZzJNU1AQAw==", "collections": { "config": [ { "Payload": { "StaticCollectionConfig": { "name": "didDocCollection", "member_orgs_policy": { "Payload": { "SignaturePolicy": { "rule": { "Type": { "NOutOf": { "n": 1, "rules": [ { "Type": { "SignedBy": 0 } }, { "Type": { "SignedBy": 1 } } ] } } }, "identities": [ { "principal": "CgdPcmcxTVNQ" }, { "principal": "CgdPcmcyTVNQ" } ] } } }, "maximum_peer_count": 1, "member_only_read": true, "member_only_write": true, "endorsement_policy": { "Type": { "SignaturePolicy": { "rule": { "Type": { "NOutOf": { "n": 1, "rules": [ { "Type": { "SignedBy": 0 } }, { "Type": { "SignedBy": 1 } } ] } } }, "identities": [ { "principal": "CgdPcmcxTVNQ" }, { "principal": "CgdPcmcyTVNQ" } ] } } } } } } ] }, "init_required": true, "source": { "Type": { "LocalPackage": { "package_id": "vdr:298182c83facca0e4613aa1e31824cb642a6a5a5aa3f99d8ee39bc502376129f" } } } } Comparing them, The presence of identical configurations suggests that both ORG1 and Org2 have approved the same chaincode definition.

[satota2]

@dc-atos-dev Certainly, it does look like both ORG1 and Org2 have approved the same chaincode definition, making root cause analysis challenging. Could you possibly share the execution flags and output results from the time you ran the failing commitreadiness command? It might help us pinpoint the issue. It might provide some insights for troubleshooting.

[Dominhthai]

I tried all of the above suggested solutions, none of them work. This is so frustrating!!!

[Dominhthai]

I already figured it out, we need to add --signature-policy at both the approveformyorg and checkcommitreadiness step.