[seeder] Make unreliable node reasons clear and consistent
ClosedPublic
Actions

Authored by PiRK on Jul 18 2024, 10:21.

Details

Reviewers

Fabien

Group Reviewers

Restricted Project

Commits

rABC2c02a0dcb3a9: [seeder] Make unreliable node reasons clear and consistent

Summary

This is a partial backport of bchn#1820
https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/merge_requests/1820/diffs?commit_id=8f435c20698488125a5f4d3759f81237acebff93

Note that I don't like the work reliableness, and reliability is already used in this codebase for another concept, so I went for ReliabilityStatus

Depends on D16905

Test Plan

run the seeder before and after this change, confirm that we get a similar number of good nodes (check for no regression)

ninja bitcoin-seeder check-seeder
src/seeder/bitcoin-seeder -dumpinterval=60

After a few minutes

awk '{ if ($2 == 1) { print } }' dnsseed.dump

Diff Detail

Repository

rABC Bitcoin ABC

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 29625
Build 58785: Build Diff	lint-circular-dependencies · build-debug · build-diff · build-without-wallet · build-clang-tidy · build-clang
Build 58784: arc lint + arc unit

Event Timeline

PiRK created this revision.Jul 18 2024, 10:21

Herald added a reviewer: Restricted Project. · View Herald TranscriptJul 18 2024, 10:21

PiRK requested review of this revision.Jul 18 2024, 10:21

teamcity edited the summary of this revision. (Show Details)Jul 18 2024, 10:21

PiRK retitled this revision from Make unreliable node reasons clear and consistent to Seeder: Make unreliable node reasons clear and consistent.Jul 18 2024, 10:22

PiRK added a child revision: D16500: [seeder] Mark nodes as unreliable until checkpoint verified.Jul 18 2024, 10:49

Harbormaster completed remote builds in B29623: Diff 48721.Jul 18 2024, 11:35

tests

Harbormaster completed remote builds in B29625: Diff 48723.Jul 18 2024, 12:44

the change in how dnsseed.dump is written (int(rep.fGood) vs rep.reliabilityStatus == ReliabilityStatus::OK ? 1 : 0) is initially wrong, because it seems to me reliabilityStatus is not actually initialized before the second time we connect to the node. Still investigating.