The error means the peer got the public hash but not the matching private data upon the prior transaction commit.
Hard to say why without knowing what happened in the past or seeing logs. You'll need to recreate the issue and look at the logs at time of commit of the original private data put on all peers. There will be a Warning in the logs for any occurrence where the peer didn't get the private data that it was authorized for.
Dave Enyeart
chintanr97---10/23/2020 12:56:41 AM---Thanks David for details. So currently, we the private data collections used by CC1 and CC2 in above
From: chintanr97@...
To: fabric@...
Date: 10/23/2020 12:56 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Chaincode to chaincode communication over private transactions #fabric-questions #fabric
Sent by: fabric@...
Thanks David for details.
So currently, we the private data collections used by CC1 and CC2 in above flow is a single collection and has policy to that of "single-org" - in each of the 3 <Get/Put>PrivateData() calls. And this particular organization is itself performing the transaction. So I guess this eliminates, cross-org scenario.
Now, I tried running the discovery protocol from CLI, using the `discover endorsers` command over peer1.Org1 (the org for which the transactions are initiated) and returns information about all the peers of Org1. Plus, the `requiredPeerCount` and `maxPeerCount` both are equal to number of peers in Org1 (>0).
So I guess, distribution of data might not be an issue.