💬 maflcko commented on pull request "test: maxuploadtarget: check for mempool msg disconnect if limit is reached, improve existing test coverage":
(https://github.com/bitcoin/bitcoin/pull/28996#issuecomment-1929096646)
lgtm ACK b58f009d9585aab775998644de07e27e2a4a8045

💬 Rodert commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929097083)
> Is it blocked forever or until the block is finished processing? Can you provide more details about what your highly concurrent request is?

this . I used golang to initiate rpc getblock and so on for the http request node, 30 concurrent continuous calls. As you can see from the load monitoring of the server, every time a new block is synchronized, the program is stuck.

💬 maflcko commented on pull request "test: fix RPC coverage check":
(https://github.com/bitcoin/bitcoin/pull/29387#issuecomment-1929108842)
Also, it doesn't seem to work, because the CI should fail, because the `abortrescan` rpc is uncovered

💬 Rodert commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929110998)
> > Package manager
>
> Which package manager?
>
> Can you provide any debug.log output?

i use bitcoin version `bitcoin-25.0` by `Linux *.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux` .

Here are some error messages encountered, But I don't know if it matters.

```bash
2024-02-05T06:13:24Z BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications
2024-02-05T06:27:32Z Saw new header hash=0000000000000000000380aa9f106ee
...

💬 Rodert commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929113601)
I've reduced the concurrency now, the problem is happening less often, but it's not completely solved

💬 maflcko commented on pull request "validation: improve performance of CheckBlockIndex":
(https://github.com/bitcoin/bitcoin/pull/28339#discussion_r1479473030)
May be better to do this deterministically to avoid non-determinism in tests?

💬 maflcko commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929125756)
`-rpcworkqueue=` should be at least as large as the number of concurrent requests you are doing.

💬 maflcko commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929130106)
`-rpcthreads=` should be at least as large as the number of concurrent requests you are doing, otherwise there won't be any threads to service the query and the work-queue will eventually overflow.

💬 vasild commented on pull request "util: check for errors after close and read in AutoFile":
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-1929136430)
Ok, the users of the class then have to explicitly close. That is 1.4. from the OP, I elaborated it with more words.

💬 scgbckbone commented on pull request "test: Add `leaf_version` parameter to `taproot_tree_helper()`":
(https://github.com/bitcoin/bitcoin/pull/29371#discussion_r1479508835)
this line should be removed and only `leaf_version` function argument should be used in the function. Both `version` and `leaf_version` will point to the same object [anyways](https://github.com/python/cpython/blob/4830f581af57dd305c02c1fd72299ecb5b090eca/Objects/longobject.c#L18-L23). Same with all possible future leaf versions [even 0xc0..0xfe](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-7)

👍 scgbckbone approved a pull request: "test: Add `leaf_version` parameter to `taproot_tree_helper()`"
(https://github.com/bitcoin/bitcoin/pull/29371#pullrequestreview-1864732480)
utACK

✅ maflcko closed an issue: "Monkey Test Feature (MTF)"
(https://github.com/bitcoin/bitcoin/issues/29389)

💬 maflcko commented on issue "Monkey Test Feature (MTF)":
(https://github.com/bitcoin/bitcoin/issues/29389#issuecomment-1929174692)
I also don't understand your "test". If there is a bug in the wallet, calling the wallet code with a different amount is not going to fix the bug. If you are worried about the created transaction, my recommendation would be to inspect it before broadcasting, as mentioned above.

In any case, no one is holding anyone back from implementing a "test". Pull requests are welcome, but I am going to close the issue for now, unless there is something specific to discuss.

💬 maflcko commented on issue "When I make a highly concurrent request to bitcoin core, a new block appears and all my requests get blocked":
(https://github.com/bitcoin/bitcoin/issues/29384#issuecomment-1929183297)
Related: #29386?

✅ maflcko closed an issue: "Incorrect amount in transaction page"
(https://github.com/bitcoin/bitcoin/issues/29378)

💬 maflcko commented on issue "Incorrect amount in transaction page":
(https://github.com/bitcoin/bitcoin/issues/29378#issuecomment-1929186223)
Closing for now, as it seems to be fixed?

💬 maflcko commented on issue "build warnings in outputtype.cpp: may be used uninitialized":
(https://github.com/bitcoin/bitcoin/issues/29359#issuecomment-1929188392)
So this may be an issue of Ubuntu/Debian refusing to apply fixes to their g++ for some reason, once released?

✅ maflcko closed a pull request: "test: Extend stale_tip_peer_management test"
(https://github.com/bitcoin/bitcoin/pull/23352)

🚀 glozow merged a pull request: "test: p2p: adhere to typical VERSION message protocol flow"
(https://github.com/bitcoin/bitcoin/pull/29353)

💬 glozow commented on pull request "test: make v2transport arg in addconnection mandatory and few cleanups":
(https://github.com/bitcoin/bitcoin/pull/29356#issuecomment-1929276821)
ACK e7fd70f4b6