Previously, wait_for_getheaders only looked for the presence of a recent "getheaders" message. Additionally checking the hashstop inside the message should make tests involving wait_for_getheaders more robust.
Issue: #18614
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Rebased.
<!--cf906140f33d8803c4a75a2196329ecb-->
🐙 This pull request conflicts with the target branch and needs rebase.
<sub>Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".</sub>
Thanks for working on this!
Yes, I agree that hash_stop is something we might consider checking. However, I'm worried that because most of the time calls to getheaders pass a hash_stop value of 0 (to indicate "get as many blocks as possible") rather than a specific block's hash value, replacing the existing logic with a hash_stop check might not actually make the tests more robust.
What do you think?