1
87%
master: 87%

Ran 16 May 2020 11:15AM UTC

Files 97

Run time 6s

Badge

Embed ▾

Committed 16 May 2020 11:15AM UTC coverage: 90.174%. Remained the same

Job # 2.7.1

Build Type

push

travis-ci

Committed by

Sjors

Commit Message

Use key?(:name) instead of [:name].present?

false.present? == false

This led to a bug in Bcash nodes.

For very old nodes that don't have a "initialblockdownload" field, there is a fallback mechanism that checks the "verificationprogress" field if that's missing.

This fallback was triggered by: blockchaininfo["initialblockdownload"].present?

Unfortutunately when  initialblockdownload is false, it would trigger the fallback, because of the above misunderstanding.

Normally that isn't a problem, but the verificationprogress is very sensitive. This is to prevent freshly added nodes from showing up as behind, and triggering alerts, instead of showing as syncing.

When there was a hard fork on bcash, the node would show a lack of progress. This is either due to an error in the progress meaurement, or  because it considers the longest header in existence, even if that's invalid. This caused the site to think the node was still syncing.

Coverage Stats

3423 of 3796 relevant lines covered (90.17%)

57.19 hits per line

BitMEXResearch / forkmonitor / 631 / 1
87%
master: 87%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 631.1 (2.7.1)

BitMEXResearch / forkmonitor / 631 / 1 87% master: 87%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 631.1 (2.7.1)

BitMEXResearch / forkmonitor / 631 / 1
87%
master: 87%

README BADGES
x