Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge #6465: fix: avoid potential divide-by-zero in network hashrate …
…stats calculation 40070c0 stats: don't report `network.*hashesPerSecond` if it's zero (Kittywhiskers Van Gogh) b39c6b9 fix: avoid potential divide-by-zero in H/s stats calculation (Kittywhiskers Van Gogh) Pull request description: ## Additional Information It was reported that on occasion, `network.*hashesPerSecond` would report NaN gauge values, which would be dismissed as malformed reporting by Grafana (see below). Those gauges use a simplified version ([source](https://github.com/dashpay/dash/blob/1ecfb891bcdcfd62db7827c55370be9bc3587f2e/src/init.cpp#L851-L864)) of `GetNetworkHashPS` ([source](https://github.com/dashpay/dash/blob/1ecfb891bcdcfd62db7827c55370be9bc3587f2e/src/rpc/mining.cpp#L61)), crucially, without a check meant to avoid divide-by-zeros ([source](https://github.com/dashpay/dash/blob/1ecfb891bcdcfd62db7827c55370be9bc3587f2e/src/rpc/mining.cpp#L89-L91)). <details> <summary>Error log (courtesy of PastaPastaPasta):</summary> ``` [...] graphite-1 | 7 Dec 21:18:05 - DEBUG: Bad line: -nan,g in msg "network.terahashesPerSecond:-nan|g" graphite-1 | 7 Dec 21:18:05 - DEBUG: Bad line: -nan,g in msg "network.petahashesPerSecond:-nan|g" graphite-1 | 7 Dec 21:18:05 - DEBUG: Bad line: -nan,g in msg "network.exahashesPerSecond:-nan|g" graphite-1 | 7 Dec 21:18:10 - DEBUG: Bad line: -nan,g in msg "network.hashesPerSecond:-nan|g" graphite-1 | 7 Dec 21:18:10 - DEBUG: Bad line: -nan,g in msg "network.terahashesPerSecond:-nan|g" graphite-1 | 7 Dec 21:18:10 - DEBUG: Bad line: -nan,g in msg "network.petahashesPerSecond:-nan|g" graphite-1 | 7 Dec 21:18:10 - DEBUG: Bad line: -nan,g in msg "network.exahashesPerSecond:-nan|g" graphite-1 | 7 Dec 21:18:15 - DEBUG: Bad line: -nan,g in msg "network.hashesPerSecond:-nan|g" [...] ``` </details> This has been resolved by adding that check, alongside encapsulating the logic in a lambda and not reporting the gauge values if the estimated hashes per second reported is zero, due to the unlikelihood of it being correct. ## Breaking Changes None expected. ## Checklist - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)** - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: UdjinM6: utACK 40070c0 knst: utACK 40070c0 Tree-SHA512: 64bcca0f51a8bebb090613d3495ddba481ea6464f9f4a6791d830593fd1401c890eba65869f8719c6c6033a3346af11f16855a95fec5f42722b26a12b9f8b3c9
- Loading branch information