Fix vc true stuck partially #286
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
peterlimg
force-pushed
the
fix/vc-true-stuck
branch
from
f9669c6
to
077ec6d
Compare
|
@peterlimg, |
Add debug log
It is hard to known what's wrong when move failed without returning error.
Even when magic block starting round is the same, the magic block may have changed, and if we don't restart the status monitor, it would inactive miners or sharders in the old pools, hence the node active status would not be updated in current magic block. This will lead further issue for calculating the TKN value when create new magic block.
In move function for contribute, the mpk keys is checked to meet the condition that len(mpks) >= dkgMinersList.K. In the following phase, sos.SignOrShare will be computed base on the mpks, one thing that need to note is the miner's own share will not be included, hence if the current mpks is 7, the sos will be 6. In the previous code, the condition for passing the phase is sos num >= dkgMinersList.N - 2, which is incorrect. As the max number of sos it can be is len(mpks) - 1, however, miners could move to current phase if the len(mpks) >= dkgMinersList.K. Therefore, if the len(mpks) == K, then len(sos) will be K - 1, as long as the N - 2 > K - 1, i.e N - 1 > K, the DKG process will fail.
Access it through methods instead, it has to be protected by mutex.
Returned block should not be able to modify the block state or update the variables.
Update node_pool locks
…nction to avoid lock concurrent accessing and updating of latestFinalizedMagicBlock
It should be safe to do this, although doing http requests in scFunc would not able to update the nodes active status, but the status monitor will update them.
This error is caused by the incorrect conflicts resolving, where the function was removed.
Stop doing unit test cases parallelly, the global config variable is not thread safe.
Push to channel may have goroutine leak if the receiver returns early
Force restart current round in HandleRoundTimeout
It would stuck the BlockMessageChannel if any function in the handler got stuck.
If there's no receiver waiting for the errC channel, the pushing would be stuck and the goroutine will be leaked.
3 seconds is too short which would lead to incorrect result of 'not registered node' and cause unnecessary repeatedly node registration.
If a request failed due to the inactive of sharder, the GetFromSharders function would get stuck in waiting for the response from collection channel.
peterlimg
force-pushed
the
fix/vc-true-stuck
branch
from
a617640
to
0cfa7e1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DO NOT
squash and mergeChanges:
getMinerNodefunction, check the node from state db first, if failed, check fromallMinersListunknown batch error