Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release: 2.2.0 #2199

Merged
merged 96 commits into from Mar 11, 2019

Conversation

Projects
None yet
7 participants
@faustbrian
Copy link
Collaborator

faustbrian commented Mar 4, 2019

Release 2.2.0

supaiku0 and others added some commits Feb 13, 2019

fix(core-api): proper hex validation (#2093)
Buffer.from(value, "hex") will only throw an exception if value is not a
string, according to
https://nodejs.org/api/buffer.html#buffer_class_method_buffer_from_string_encoding
Indeed Buffer.from('foo', 'hex') does not throw. The schema has defined
`type: "string"`, which means that, in all cases when the validate
method is called, it will return true.

Use a proper validation using regular expression and a length check.
refactor(core-p2p): remove broken getRandomDownloadBlocksPeer() (#2121)
getRandomDownloadBlocksPeer() would end up in an "infinite" recursion
loop if the chain of the node is >10 blocks forked from the chain of all
other nodes. This is because __getRecentBlockIds() returns just the
highest 10 blocks of the node's chain.

getRandomDownloadBlocksPeer() is not necessary with peer verification
because during peer verification we check for common blocks in a more
robust way (not just the highest 10), going back to the genesis block if
necessary. So, for sure, if a peer is verified, we know that he has
common blocks with us. If a peer could not be verified, then he would
not be in the list of our peers. Thus, just use getRandomPeer() instead
of getRandomDownloadBlocksPeer().

Also, improve some diagnostic messages to contain a reason why a
failure occurred.

faustbrian and others added some commits Mar 4, 2019

refactor(core-forger): Increase timeout for getting the network state (
…#2208)

* refactor(core-forger): Increase timeout for getting the network state

The 2 seconds timeout is too short and can unnecessary blow up the
forging process in cases where it is possible to forge successfully.

Set it to an arbitrary 7 seconds which is block time minus 1 second for
other activities.

Elaborate log messages by explicitly saying "Will not forge" + an
explanation "why" when the code would decide not to forge.

* Increase the timeout to only 4s to leave more time for propagation
feat(core-p2p): Don't spoil the quorum if the peer has !forgingAllowed (
#2214)

We need >66% quorum to forge and thus we should not count peers that
report "forgingAllowed: false" towards no-quorum ones, because too many
such peers could trip the forger to skip a block.

@faustbrian faustbrian marked this pull request as ready for review Mar 11, 2019

@faustbrian faustbrian requested review from kristjank and supaiku0 as code owners Mar 11, 2019

faustbrian added some commits Mar 11, 2019

@faustbrian faustbrian merged commit ac778f8 into master Mar 11, 2019

6 checks passed

ci/circleci: test-node10-0 Your tests passed on CircleCI!
Details
ci/circleci: test-node10-1 Your tests passed on CircleCI!
Details
ci/circleci: test-node10-2 Your tests passed on CircleCI!
Details
ci/circleci: test-node11-0 Your tests passed on CircleCI!
Details
ci/circleci: test-node11-1 Your tests passed on CircleCI!
Details
ci/circleci: test-node11-2 Your tests passed on CircleCI!
Details

@faustbrian faustbrian deleted the 2.2 branch Mar 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.