💬 hebasto commented on pull request "Add public Boost headers explicitly":
(https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1210613769)
I see no point at all. Is it OK to put this change into this PR ?

💬 hebasto commented on pull request "Add public Boost headers explicitly":
(https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1210614349)
Or I can just revert the recent change?

💬 MarcoFalke commented on pull request "Add public Boost headers explicitly":
(https://github.com/bitcoin/bitcoin/pull/27783#discussion_r1210615011)
I meant moving everything to the cpp file, but they are included via txmempool.h either way, so while everything can be moved to the cpp file, it doesn't matter.

💬 erikarvstedt commented on issue "bitcoind hangs waiting for `g_requests.empty()`":
(https://github.com/bitcoin/bitcoin/issues/27722#issuecomment-1568888056)
A similar bug appears in the [nix-bitcoin](https://github.com/fort-nix/nix-bitcoin/) [test suite](https://github.com/fort-nix/nix-bitcoin/blob/master/test/tests.py).

The test is executed inside a QEMU VM and runs `bitcoind` together with a bunch of client services (like `clightning`, `lnd`, `joinmarket`). It then stops all services, including `bitcoind`.
Sometimes `bitcoind` hangs during shutdown:
1. First, it waits for a few minutes at [httpserver.cpp#L469](https://github.com/bitcoin/bitco
...

📝 mzumsande opened a pull request: "test: fix intermittent error in getblockfrompeer.py"
(https://github.com/bitcoin/bitcoin/pull/27784)
This adds an additional `sync_blocks` call, fixing an intermittent error caused by blocks arriving out of order due to how compact block relay may revert to headers processing when the tip hasn't caught up, and resulting in slightly different pruning behavior.
Making sure that all blocks from the previous tests are synced before generating more blocks makes this impossible.

See https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1566354933 and https://github.com/bitcoin/bitcoin/iss
...

💬 mzumsande commented on issue "rpc_getblockfrompeer.py intermittent failure: assert_equal(pruneheight, 248); not(249 == 248)":
(https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1568894113)
Opened #27784 which just adds an additional sync, as suggested in https://github.com/bitcoin/bitcoin/pull/27770#issuecomment-1567870784 .

💬 brunoerg commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1210698732)
In 30c39c1316a7b5c1914654f2a1487309b6e550ac: If we're in IBD, wouldn't we put that peer in the end of the queue with no need (I mean, without doing a rec request in fact)?

💬 Crypt-iQ commented on issue "bitcoind hangs waiting for `g_requests.empty()`":
(https://github.com/bitcoin/bitcoin/issues/27722#issuecomment-1568965050)
@erikarvstedt it seems like there's a call to `importmulti` that is outstanding while bitcoind is trying to shut down

💬 aureleoules commented on pull request "ci: Add test coverage job":
(https://github.com/bitcoin/bitcoin/pull/27547#discussion_r1210750673)
Done thanks. I rolled back to jammy.

💬 aureleoules commented on pull request "ci: Add test coverage job":
(https://github.com/bitcoin/bitcoin/pull/27547#issuecomment-1568997159)
> I presume there is a setting to disable the comment and just have DrahtBot add a link in the form of https://app.codecov.io/gh/{owner}/{repo}/pull/{number} to the summary comment?

Yes there is. Done in 320eb03aeb097f6d14757c66a1b0bf40d0473b88.

👍 theStack approved a pull request: "test: fix intermittent error in getblockfrompeer.py"
(https://github.com/bitcoin/bitcoin/pull/27784#pullrequestreview-1451720045)
ACK 9fe9074266c6d7ddb40384d81741df1fc94980ff

Unfortunately there seems to be no reliable way to reproduce the issue on master (which could then be also ran on this PR to ensure that it is indeed fixed), but the explanation in https://github.com/bitcoin/bitcoin/issues/27749#issuecomment-1566554075 makes sense to me.

💬 pinheadmz commented on pull request "ZMQ: Support UNIX domain sockets":
(https://github.com/bitcoin/bitcoin/pull/27679#issuecomment-1569013910)
> 🐙 This pull request conflicts with the target branch and [needs rebase](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes).

Relax bot! sheesh. I'm gonna wait until #27375 gets approved

💬 Sjors commented on pull request "test: fix intermittent error in getblockfrompeer.py":
(https://github.com/bitcoin/bitcoin/pull/27784#issuecomment-1569023147)
9fe9074266c6d7ddb40384d81741df1fc94980ff looks harmless, but I haven't delved into the underlying issue. Can the original be reproduced by running the test in a loop??

CI failure seems spurious.

💬 theStack commented on pull request "Fix rpc_getblockfrompeer intermittency by introducing 'getblockfileinfo' RPC command":
(https://github.com/bitcoin/bitcoin/pull/27770#issuecomment-1569050370)
I agree with @furszy and @mzumsande that a `getblockfileinfo` RPC could be quite handy, both for making some of the pruning-related tests more robust and readable (potentially eliminating some magic numbers that can only be explained by the one who introduced them) and also for testing AssumeUTXO. As an illustration, the blocks directory of a mainnet test-run of AssumeUTXO ended up at some point like this on my disk:
```
$ ls -l ./datadir2/blocks/blk*.dat
-rw------- 1 thestack thestack 13
...

💬 pinheadmz commented on pull request "net: support unix domain sockets for -proxy and -onion":
(https://github.com/bitcoin/bitcoin/pull/27375#issuecomment-1569053476)
> 🐙 This pull request conflicts with the target branch and [needs rebase](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes).

🕺

💬 mzumsande commented on pull request "test: fix intermittent error in getblockfrompeer.py":
(https://github.com/bitcoin/bitcoin/pull/27784#issuecomment-1569054690)
> Can the original be reproduced by running the test in a loop??

I haven't been able to reproduce it, I think it requires a constellation with a very special timing which should make it very rare even in the CI. One thing I did is check in the log is that node2 doesn't use `HeadersDirectFetchBlocks` for any blocks > 205, and uses compact block reconstruction instead. This is different in the log of the failed run.

💬 theStack commented on pull request "test: fix intermittent error in getblockfrompeer.py":
(https://github.com/bitcoin/bitcoin/pull/27784#issuecomment-1569062154)
> [9fe9074](https://github.com/bitcoin/bitcoin/commit/9fe9074266c6d7ddb40384d81741df1fc94980ff) looks harmless, but I haven't delved into the underlying issue. Can the original be reproduced by running the test in a loop??

If you want to give that approach a try, the following shell script (which I have been running for days already, without any issue) should do exactly that:
```bash
#!/usr/bin/env bash
set -e
while true; do ./test/functional/rpc_getblockfrompeer.py; done
```

💬 erikarvstedt commented on issue "bitcoind hangs waiting for `g_requests.empty()`":
(https://github.com/bitcoin/bitcoin/issues/27722#issuecomment-1569074534)
@Crypt-iQ, the slow progress of `importmulti` is indeed a separate issue. I've updated my post.

💬 willcl-ark commented on pull request "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py":
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1210781561)
Import helper from _test_framework.messages_?

```suggestion
new_data_hash = hash256(new_data)

```

💬 willcl-ark commented on pull request "test: cover addrv2 anchors by adding TorV3 to CAddress in messages.py":
(https://github.com/bitcoin/bitcoin/pull/27452#discussion_r1210795850)
Why do we need to keep the `Socks5Server` alive to ensure success when performing `"Check for addrv2 addresses in anchors.dat"`?

I changed this to `False` and saw intermittent failures on Line 123

```
assert_equal(data[services_index], 0x00) # services == NONE
```