LAB 8: Peers approved but cannot commit

Hi I'm stuck at the same point

Lab 08 page 12 of the PDF at Chaincode Initialization

I have my chaincode sacc v1.0 sequence 2 commited with the custom endorsement policy (OR)

I can Invoke this chaincode with only 1 peer like this :
peer chaincode invoke -o orderer.example.com:7050 --tls --cafile $ORDERER_TLS_CA -C allarewelcome -n sacc --peerAddresses $CORE_PEER_ADDRESS --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE -c '{"function":"set","args":["key2", "value2"]}' --waitForEvent
So I know my endorsement policy as been updated correctly.

But I cannot approve the sequence 3

Why does it ask for 2 approval since the EP has been updated to OR ?
And why it's still showing false to the approval ?

I tried to change the ENV variables to bootstrap the peer0 of org1 then org2 -> nothing

I tried to add this option --signature-policy "OR('Org1MSP.peer', 'Org2MSP.peer')" -> still nothing

Any Ideas ?

I'll try to do it again but to not change the endorsement policy to see what happen.

Finally I got it through. What I did is:
1. I use Mac and native Docker. I followed advice online to turn off gRPC FUSE.
2. Make sure all bootstraps go well and all processes of peer lifecycle chaincode install, approveformyorg and commit are done with both peer0 org1 and org2. If anything goes wrong, gotta fix it before move on. otherwise start from scratch
3. Make sure export CC_PACKAGE_ID= the PACKAGE_ID is entered correctly. It includes sacc1.0:xxxx.
4. peer lifecycle chaincode checkcommitreadiness to confirm approvals are true for both MSPs
5. After upgrade, use --init-required when approveformyorg

If it goes smooth without getting messed on those commands and parameters, the invoke command could be executed well. I can make several times of upgrade and add new key-value pair in each version. Good luck!

Stuck exactly at the same error @TriumphS . Cannot commit sequence 2, even when is approved by both Org1MSP and Org2MSP

Yes @Bobbijn I completed that section on page 11, and then made the **Try it yourself **

`export CORE_PEER_LOCALMSPID=Org1MSP

export CORE_PEER_ADDRESS=peer0.org1.example.com:7051

export CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt

export CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key

export CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt

export CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp

peer lifecycle chaincode approveformyorg -o orderer.example.com:7050 --tls --cafile $ORDERER_TLS_CA --channelID allarewelcome --name sacc --version 1.0 --package-id $CC_PACKAGE_ID --sequence 2 --signature-policy "OR('Org1MSP.peer', 'Org2MSP.peer')"

2021-04-02 00:13:10.757 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [4ac853153342e27639d84da861f569b66c24e399f35befc9d0628e5a9910a39f] committed with status (VALID) at peer0.org1.example.com:7051

peer lifecycle chaincode checkcommitreadiness --channelID allarewelcome --name sacc --version 1.0 --sequence 2 --output json --signature-policy "OR('Org1MSP.peer', 'Org2MSP.peer')"
{
"approvals": {
"Org1MSP": true,
"Org2MSP": true
}
}
`

Ok thanks

@angelparrales Hello, Still trying to determine the best way we can get to the bottom of this situation. Have you tried the solution samuelslleung posted on March 4th? Bobbi

@angelparrales,

Hello, I have a resource you can use to gain more information about the issue you are experiencing( hyperledger-fabric@lists.hyperledger.org ) . I am hosting the Learning Material Working Group call today and will bring up your issue during the call. Please feel free to join the call, details can be found here: https://wiki.hyperledger.org/display/LMDWG/Learning+Materials+Development+Working+Group

Bobbi

I ran into this error today. I had successfully done this in the past and I did not understand how i got this error.
Some one would have to double check IMAGE_TAG=2.3
I reverted my lab08 to IMAGE_TAG=2.2
But i noticed that my CC_PACKAGE_ID value was missing characters the second time I went through the lab.
MAKE SURE YOU ARE COPYING THE WHOLE package-id
bash-5.1# peer lifecycle chaincode queryinstalled Installed chaincodes on peer: Package ID: sacc_1.0:5562f868f6fd43ff8873f403aa52bc6928161fec933065d0b81e2193f6038bd0, Label: sacc_1.0
in my terminal the last 3 digits were on the next line and i missed the copy, which pasted the wrong package-id.

Iff your terminal is too small the rest of the package id is on the following line when you copy from command line..
good luck!

@brentbrownfield, Let see if we can work through this. The Labs are set up to run in order, so If an error exists from a previous exercise it will affect current exercises. It is best to start the lab from the beginning making sure all the steps run properly. To make changes in a production environment Hyperledger offers real-time support by the project maintainers. Join the Mailing list at: https://lists.hyperledger.org/g/fabric. You can ask the project maintainers questions about the production environment here.

Hope this Helps, Bobbi

Running from the beginning of lab 8 works up until after adding the custom endorsement policy. I successfully executed the endorsement policy, including approving on both Org1 and Org2, specifying the signature policy in both the approve and commit. I do not see any way to verify that the policy was properly set.

I then proceed to section Chaincode Initialization and run the following commands exactly as outlined in the document, and it still fails.

bash-5.0# peer lifecycle chaincode approveformyorg -o orderer.example.com:7050 --tls --cafile $ORDERER_TLS_CA --channelID allarewelcome --name sacc --version 1.0 --package-id $CC_PACKAGE_ID --sequence 3 --init-required
 
2021-12-08 18:15:25.726 UTC [chaincodeCmd] ClientWait -> INFO 001 txid [8ff32b4faa8b23bce09ff4c0fb46cfcddfb81dd71d32e2f2297b8331927745d8] committed with status (VALID) at peer0.org2.example.com:7051

Then:

bash-5.0# peer lifecycle chaincode checkcommitreadiness --channelID allarewelcome --name sacc --version 1.0 --sequence 3 --output json --signature-policy "OR('Org1MSP.peer', 'Org2MSP.peer')"
 
{
        "approvals": {
                "Org1MSP": false,
                "Org2MSP": false
        }
}

Does the signature policy need to be specified here as well or only up until it is committed? It seems something crucial is left out of the training course and left up to the user to figure out.

The course material states:

As discussed previously in this lab, one more approval is required before the new chaincode
definition can be committed and becomes active on the channel. We leave doing so (and
invoking the chanincode) as an exercise to the reader

Is it mandatory to invoke the chaincode after approving for Org1 & committing?

@brentbrownfield,
Great job! I will make note of this solution and pass it on to other learners experiencing the same issue.
Bobbi

Ok, so I needed to add --signature-policy "OR('Org1MSP.peer', 'Org2MSP.peer')" to my commit command, like so:

peer lifecycle chaincode commit \
-o orderer.example.com:7050 \
--tls --cafile $ORDERER_TLS_CA \
--channelID allarewelcome \
--name sacc \
--version 1.0 \
--sequence 2 \
--peerAddresses $CORE_PEER_ADDRESS \
--tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE \
--peerAddresses peer0.org1.example.com:7051 \
--tlsRootCertFiles /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt \
--signature-policy "OR('Org1MSP.peer', 'Org2MSP.peer')"