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

backport: Merge #21201, 21310 #6060

Closed
wants to merge 1 commit into from
Closed

Conversation

vijaydasmp
Copy link

bitcoin backports

@vijaydasmp vijaydasmp changed the title backport: Merge #20524: test: Move MIN_VERSION_SUPPORTED to p2p.py backport: Merge #20524 Jun 13, 2024
@vijaydasmp vijaydasmp changed the title backport: Merge #20524 backport: Merge #20524, 21201, 19668, 21202, 21310, 21345 Jun 15, 2024
Copy link

This pull request has conflicts, please rebase.

@vijaydasmp vijaydasmp force-pushed the bp22_100 branch 3 times, most recently from 93b49e8 to 39535a7 Compare July 20, 2024 11:40
@vijaydasmp vijaydasmp changed the title backport: Merge #20524, 21201, 19668, 21202, 21310, 21345 backport: Merge #21201, 19668, 21202, 21310 Jul 20, 2024
Copy link

This pull request has conflicts, please rebase.

@vijaydasmp vijaydasmp changed the title backport: Merge #21201, 19668, 21202, 21310 backport: Merge #21201, 21202, 21310 Aug 3, 2024
@vijaydasmp vijaydasmp force-pushed the bp22_100 branch 2 times, most recently from 2dcd3dd to 496afd8 Compare August 4, 2024 06:21
@vijaydasmp vijaydasmp changed the title backport: Merge #21201, 21202, 21310 backport: Merge #21201, 21310 Aug 4, 2024
…o generated block

8a8c638 zmq test: fix sync-up by matching notification to generated block (Sebastian Falbesoner)

Pull request description:

  This is a follow-up PR for bitcoin#21008, fixes bitcoin#21216.

  In the course of investigating the problem with jnewbery (analyzing the Cirrus log https://cirrus-ci.com/task/4660108304056320), it turned out that the "sync up" procedure of repeatedly generating a block and waiting for a notification with timeout is too brittle in its current form, as the following scenario could happen:

  - generate block A
  - receive notification, timeout happens => repeat procedure
  - generate block B
  - node publishes block A notification
  - receive notification, we receive the one caused by block A (!!!) => sync-up procedure is completed
  - node publishes block B notification
  - the actual test starts
  - on the first notification reception, the one caused by block B is received, rather than the one actually caused by test code => assertion failure

  This change in the PR ensures that after each test block generation, we wait for the notification that is actually caused by that block and ignore others from possibly earlier blocks. The matching is kind of ugly, it assumes that one out of four components in the block is contained in the notification: the block hash, the tx id, the raw block data or the raw transaction data. (Unfortunately we have to support all publisher topics.)

  I'm aware that this is quite a lot of code now only for establishing a robust test setup. OTOH I wouldn't know of a better method right now, suggestions are very welcome.

  Note for potential reviewers: for both reproducing the issue on master branch and verifying on PR branch, one can simply generate two blocks in the sync-up procedure rather than one.

ACKs for top commit:
  MarcoFalke:
    Concept ACK 8a8c638

Tree-SHA512: a2eb78ba06dfd0fda7b1c111b6bbfb5dab4ab08500cc19c7ea02c3239495d5c74cc7d45250a8b3ecc78ca42d97ee6719bf73db8a137839e5e09a3cfcf08ed29e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant