Changing endorsement policy to require multiple members, but not sure how to get all peers to endorse - hyperledger-fabric

Question

My chaincode was instantiated with the following command:
peer chaincode instantiate -o orderer1.example.com:7050 --tls true --cafile <cafile> -C mychannel
-n mycc -l java -v 1.0 -c '{"Args":[]}' -P "OR ('Org1MSP.member')"
I would like to change the endorsement policy such that all peers in the organization are required for endorsement; currently I have two peers, but the number is set to increase.
What I do for now is the following procedure:
Step one: install the same chaincode with a different version name.
peer chaincode install -n mycc -v <version> -l java -p /opt/gopath/src/github.com/chaincode
Step two: upgrade the chaincode using the following command:
peer chaincode upgrade -o orderer1.example.com:7050 --tls true --cafile <cafile> -C mychannel
-n mycc -l java -v <version> -c '{"Args":[]}' -P "OutOf(2, 'Org1MSP.member')"
-peerAddresses peer1.org1.example.com:7051 -peerAddresses peer2.org1.example.com:7051
However, I am unable to achieve my desired outcome. Under the current endorsement policy, when I use my my client to submit a transaction, it is committed after a while. After I change the policy, my transaction is no longer automatically accepted, and the logs reflect this with the following error message:
VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode
mycc in tx 132:0 failed: signature set did not satisfy policy
So while I am able to stop the auto-acceptance of transactions, now I find myself unable to validate any transaction.
The procedure I follow in changing the chaincode endorsement policy, is it correct?
Does my endorsement policy do what I intend to do?
How come I am no longer able to validate transactions?
EDIT: I changed my logging spec to the one suggested by Jason Yellick. I think I found some debug which might provide insight:
<time> [cauthdsl] func1 -> DEBU 4bd 0xc0004e4050 gate 1594275943563937246 evaluation starts
<time> [cauthdsl] func2 -> DEBU 4be 0xc0004e4050 signed by 0 principal evaluation starts (used [false])
<time> [cauthdsl] func2 -> DEBU 4bf 0xc0004e4050 processing identity 0 with bytes of 1159660
<time> [cauthdsl] func2 -> DEBU 4c0 0xc0004e4050 principal matched by identity 0
<time> [cauthdsl] func2 -> DEBU 4c1 0xc0004e4050 principal evaluation succeeds for identity 0
<time> [cauthdsl] func2 -> DEBU 4c2 0xc0004e4050 signed by 1 principal evaluation starts (used [true])
<time> [cauthdsl] func2 -> DEBU 4c3 0xc0004e4050 skipping identity 0 because it has already been used
<time> [cauthdsl] func2 -> DEBU 4c4 0xc0004e4050 principal evaluation fails
<time> [cauthdsl] func1 -> DEBU 4c5 0xc0004e4050 gate 1594275943563937246 evaluation fails
<time> [vscc] Validate -> ERRO 4c6 VSCC error: stateBasedValidator.Validate failed, err validation of endorsement policy for chaincode myteacc in tx 140:0 failed: signature set did not satisfy policy
<time> [vscc] Validate -> DEBU 4c7 block 140, namespace: myteacc, tx 0 validation results is: validation of endorsement policy for chaincode myteacc in tx 140:0 failed: signature set did not satisfy policy
<time> [committer.txvalidator] ValidateWithPlugin -> DEBU 4c8 Transaction 1d8f66a10658c3d808ad4ce0feef9fd5c13816187a39fcedc8a32ce91016df0d appears to be invalid: validation of endorsement policy for chaincode myteacc in tx 140:0 failed: signature set did not satisfy policy
<time> [committer.txvalidator] validateTx -> ERRO 4c9 VSCCValidateTx for transaction txId = 1d8f66a10658c3d808ad4ce0feef9fd5c13816187a39fcedc8a32ce91016df0d returned error: validation of endorsement policy for chaincode myteacc in tx 140:0 failed: signature set did not satisfy policy
<time> [committer.txvalidator] validateTx -> DEBU 4ca [isprintchannel] validateTx completes for block 0xc0026306c0 env 0xc00245e190 txn 0
This is with policy set to AND('Org1MSP.member','Org1MSP.member')

Answer 1

Your endorsement policy is unsatisfiable. In your upgrade command:
peer chaincode upgrade -o orderer1.example.com:7050 --tls true
--cafile <cafile> -C mychannel -n mycc -l java -v <version>
-c '{"Args":[]}' -P "OutOf(2, 'Org1MSP.member')"
-peerAddresses peer1.org1.example.com:7051 -peerAddresses
peer2.org1.example.com:7051
you can see that your policy is:
-P "OutOf(2, 'Org1MSP.member')"
This endorsement policy is requiring that "2 out of 1 identities must sign". This can never be satisfied, as you can never have more signatures than principles. It is essentially saying "Of 1 thing, pick 2 of them", which is a contradiction. If you really want to require two peers from the same organization, then you would want to write:
-P "OutOf(2, 'Org1MSP.member', 'Org1MSP.member')"
Or, you could have simply used the AND syntax:
-P "AND('Org1MSP.member', 'Org1MSP.member')"
I would note, it's unusual to require multiple peers from the same organization to endorse, and if you go this route, you need to be careful in your certificate management. In particular, if you are using the fabric-ca, you must ensure that the peer identity can only enroll once, otherwise it could re-enroll and now have two valid identities, and be able to pretend to be two different peers. Similarly, if the identity must be re-issued, be careful to ensure that the old certificate is revoked.
You might consider instead defining a second logical organization and writing your policies using the two distinct logical organizations such as:
-P "AND('Org1MSP.member', 'Org2MSP.member')"
This is a much more conventional way to operate Fabric.