Re: Wrong world state #fabric #fabric-questions

David Enyeart

We haven't seen such a problem in Fabric system tests (e.g. there are tests that repeatedly crash peers and ensures that peer restart recovers in-flight data with correct data integrity). The occurrences we've seen have been due to things like mounting incorrect database volumes or having data left over from a prior trial. Not that it would be impossible for there to be a bug in the state database code, but nobody has opened such an issue. So if you can reproduce such a problem, please open a bug in Jira with reproduction steps.

If you do get into a bad state, the 'bad' peer won't be able to impact the network... transaction endorsements from a 'bad' peer won't match endorsements from 'good' peers for the afflicted keys, therefore your client application should detect such a problem, and if such a transaction were submitted to the channel anyways, it would be invalidated by all peers due to the mismatched endorsements.

Dave Enyeart

"Joao Antunes" ---11/08/2019 04:43:06 PM---Hi, Recently I got a strange behaviour in my network regarding ledger height, that was not consisten

From: "Joao Antunes" <joao.antunes@...>
To: fabric@...
Date: 11/08/2019 04:43 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Wrong world state #fabric #fabric-questions
Sent by: fabric@...


Recently I got a strange behaviour in my network regarding ledger height, that was not consistent.

I solved that issue but, after a bit more investigation, I found that some values in world state were not correct. I used "peer node reset" across all my peers and the value was corrected. So is it correct of me to assume that the ledger is correct but the world state is not? How can this happen?

My setup, is 4 peers, 2 orderers, 2 ca and 2 orgs (2 peers, 1 orderer and 1 ca in each). I'm also using kafka setup. To communicate with the Fabric, I'm using Java SDK.

Join to automatically receive all group messages.