util: cap Sock::WaitMany timeout to fix -rpcclienttimeout=0 on macOS #36340

kriss39 commented at 9:40 AM on September 26, 2026: contributor

bitcoin-cli -rpcclienttimeout=0 is documented as "no timeout", but on macOS it fails with "Could not connect to the server" since #34342 (it's in v32.0rc1/rc2).

bitcoin-cli turns 0 into std::chrono::years(5) and passes it to Sock::Wait. On platforms without USE_POLL (everything except Linux) WaitMany uses select(), and macOS returns EINVAL for timeouts above 10^8 seconds. Five years is about 1.58 * 10^8 s. The same happens with any explicit value above 10^8, e.g. -rpcclienttimeout=110000000. On Linux, poll() takes the timeout as an int, so the millisecond count gets narrowed. For five years this happens to wrap to a negative value, which means infinite, so it works there by accident.

This caps the timeout in Sock::WaitMany at INT_MAX milliseconds (about 24.8 days). That fits poll() and is below the 31 days POSIX requires select() to support. Doing it in WaitMany covers every caller, not only bitcoin-cli.

The new sock_tests/wait_large_timeout test waits with a 5 year timeout on a socket that already has data. It fails on master on macOS and passes with this change. I also checked by hand on macOS that -rpcclienttimeout=0, 157784760 and 2147483647 work against a running node, and interface_bitcoin_cli.py still passes.

This doesn't overlap with #36299, which changes how the timeout is counted but still passes the 5 year value down.

DrahtBot added the label Utils/log/libs on Sep 26, 2026

DrahtBot commented at 9:40 AM on September 26, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

External sites

Code coverage & benchmarks: https://corecheck.dev/bitcoin/bitcoin/pulls/36340
Ralph review <img src=https://review.fish.foo/assets/bitcoin/bitcoin/36340.png alt="Ralph review status"> https://git.fish.foo/bitcoin/bitcoin/pulls/36340#author-ralph

Reviews

See the guideline and AI policy for information on the review process.

Type	Reviewers
ACK	fjahr, winterrdog, ismaelsadeeq, pinheadmz
Concept ACK	l0rinc

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.

Conflicts

No conflicts as of last run.

kriss39 force-pushed on Sep 26, 2026

DrahtBot added the label CI failed on Sep 26, 2026

DrahtBot removed the label CI failed on Sep 26, 2026

winterrdog commented at 1:46 PM on September 26, 2026: contributor

concept ACK

could we handle the "no timeout" case using the OS primitives' native indefinite timeout, while keeping this cap for explicitly specified large finite timeouts ?

since poll() supports a negative timeout and select() can take NULL, that would preserve the -rpcclienttimeout=0 semantics without removing the protection against very large finite values

references:

Linux poll(2)
FreeBSD select(2)
OpenBSD select(2)
NetBSD select(2)
Windows select()

[!NOTE] i do not have an Apple machine to check the macOS local manpages. so macOS users can just check the authoritative local versions with man 2 select and man 2 poll

kriss39 commented at 2:47 PM on September 26, 2026: contributor

thanks! good call, pushed a second commit that does this.

you're right that the cap alone isn't really "no timeout". HTTPClient::Recv treats any wait that comes back empty as a timeout, so -rpcclienttimeout=0 would have given up after ~24.8 days of silence. I doubt anyone is going to keep a waitfornewblock open for three and a half weeks, but "no timeout" should probably mean no timeout.

fwiw the 5 years was never really "no timeout" either. it's a leftover from libevent, which just couldn't wait indefinitely (b3b26e149c).

I do have a Mac on my desk, so here's what the man pages say: select(2) "blocks indefinitely" with a NULL timeout and returns EINVAL if the timeout is "negative or too large". poll(2) blocks indefinitely with -1. same as the BSDs.

what the new commit does:

adds Sock::NO_TIMEOUT (milliseconds::max()), which WaitMany passes as -1 to poll() and nullptr to select()
bitcoin-cli uses it for -rpcclienttimeout=0 instead of 5 years
the cap from the first commit stays for large finite values like -rpcclienttimeout=110000000

added sock_tests/wait_no_timeout. I also checked by hand on macOS that -rpcclienttimeout=0 waitfornewblock waits until a block comes in, and that -rpcclienttimeout=1 still times out.

this will conflict with #36299 since both touch the deadline code in cli. whichever goes in second gets a small rebase.

maflcko added this to the milestone 32.0 on Sep 28, 2026

maflcko added the label Needs Backport (32.x) on Sep 28, 2026

maflcko added the label macOS on Sep 28, 2026

maflcko commented at 7:32 AM on September 28, 2026: member

I wonder how much we want to backport here. I doubt there is a use case to have a timeout of more than a few hours, so capping to 1 day, or even 14 days, or the first commit should be fine for a backport?

kriss39 force-pushed on Sep 28, 2026

winterrdog commented at 7:56 AM on September 28, 2026: contributor

capping to 1 day

I agree. The second commit might've gone overboard

kriss39 commented at 7:56 AM on September 28, 2026: contributor

makes sense, dropped the second commit so this is just the cap in Sock::WaitMany and should be easy to backport. that fixes both -rpcclienttimeout=0 and large explicit values; 0 now effectively means ~24.8 days, which as you say is way beyond any real use. @winterrdog the native infinite wait (poll -1 / select NULL) can go in a follow-up if people still want it.

winterrdog commented at 8:06 AM on September 28, 2026: contributor

the native infinite wait (poll -1 / select NULL) can go in a follow-up if people still want it.

A protracted wait timeout is simple and does the job fine. So, no need to get dogmatic about native infinite wait

Approach ACK

in src/util/sock.cpp:168 in a9d2316b50

 162 | @@ -162,6 +163,11 @@ bool Sock::Wait(std::chrono::milliseconds timeout, Event requested, Event* occur
 163 |  
 164 |  bool Sock::WaitMany(std::chrono::milliseconds timeout, EventsPerSock& events_per_sock) const
 165 |  {
 166 | +    // poll() takes the timeout as an int, and select() fails with EINVAL on some systems
 167 | +    // (e.g. macOS) for timeouts above 10^8 seconds. POSIX only requires select() to accept
 168 | +    // up to 31 days, so cap the timeout at INT_MAX milliseconds (about 24.8 days).

winterrdog commented at 1:21 PM on September 28, 2026:

nit: since the commit message already carries most of the detail, can we make the comment a lot shorter. maybe sth like:

diff --git a/src/util/sock.cpp b/src/util/sock.cpp
index 7212f39b08..dc85f1fc17 100644
--- a/src/util/sock.cpp
+++ b/src/util/sock.cpp
@@ -163,9 +163,8 @@ bool Sock::Wait(std::chrono::milliseconds timeout, Event requested, Event* occur

 bool Sock::WaitMany(std::chrono::milliseconds timeout, EventsPerSock& events_per_sock) const
 {
-    // poll() takes the timeout as an int, and select() fails with EINVAL on some systems
-    // (e.g. macOS) for timeouts above 10^8 seconds. POSIX only requires select() to accept
-    // up to 31 days, so cap the timeout at INT_MAX milliseconds (about 24.8 days).
+    // Very large timeouts (above 10^8 seconds) break things: poll() only takes an int and select()
+    // fails outright on some systems (e.g. macOS). So we cap it at INT_MAX (~24.8 days).
     timeout = std::min(timeout, std::chrono::milliseconds{std::numeric_limits<int>::max()});

 #ifdef USE_POLL

</details>

what do you think ?

in src/test/sock_tests.cpp:167 in a9d2316b50 outdated

 162 | +
 163 | +    // bitcoin-cli uses a 5 year timeout for -rpcclienttimeout=0. The data is already
 164 | +    // there, so the wait must succeed right away instead of failing on the timeout value.
 165 | +    Sock::Event occurred{0};
 166 | +    BOOST_CHECK(socks.receiver.Wait(std::chrono::years{5}, Sock::RecvEvent, &occurred));
 167 | +    BOOST_CHECK(occurred & Sock::RecvEvent);

winterrdog commented at 2:00 PM on September 28, 2026:

the test currently has the data ready before we call Wait(). was that intentional ?

i am wondering if we should instead have Wait() start first, and then send a few bytes, so that we actually make select()/poll() wait with the large timeout. sth like starting Wait() in a separate thread, waiting briefly (say 50 or 100 ms), then sending the data from the main thread. that way we exercise the full Wait() path with the large timeout passed and make sure it completes without a hitch, rather than just checking that Wait() accepts it

or is the current test enough to cover the regression ?

kriss39 force-pushed on Sep 28, 2026

kriss39 commented at 2:44 PM on September 28, 2026: contributor

@winterrdog thanks, took both. The comment is shortened as you suggested, and the test now starts Wait() in a thread with the 5 year timeout and only sends the data after 100ms, so select()/poll() really wait with it. Without the cap it still fails on macOS (the wait returns false right away), with the cap it passes. Kept it as a single commit for the backport.

winterrdog commented at 1:37 PM on September 29, 2026: contributor

from: #36340 (comment)

I doubt anyone is going to keep a waitfornewblock open for three and a half weeks, but "no timeout" should probably mean no timeout.

from: #36340 (comment)

I doubt there is a use case to have a timeout of more than a few hours, so capping to 1 day, or even 14 days

those 2 comments got me thinking.. about this:

https://github.com/bitcoin/bitcoin/blob/dc2a9987aab711abdc1a77aa6d1462c6a46deabd/src/bitcoin-cli.cpp#L1205-L1206

why don't we use sth much shorter than 5 years? even 1-4 days feels like plenty of room here

i mean.. contemporary humans are known to get frustrated when a webpage takes more than 7-10 seconds to load. if someone is still waiting for an RPC response after 6 hours (or even 30 minutes), they have probably entered a new dimension of patience

i think this could be a follow-up if we do not want to make the PR's diff bigger. just throwing the idea out there.

what do you think ?

kriss39 commented at 9:06 PM on September 29, 2026: contributor

agree 5 years doesn't mean much in practice, and with the cap it's already ~24.8 days at most anyway. I'd rather keep this PR as is so it stays a small backport though. Changing what 0 means would also need the help text updated, since it currently says "0 for no timeout", so it seems like its own discussion. Happy to open a follow-up for it after this one, or review yours if you want to take it.

winterrdog commented at 9:12 PM on September 29, 2026: contributor

Happy to open a follow-up for it after this one,

Sure. That's fine

kriss39 commented at 9:24 PM on September 29, 2026: contributor

Happy to open a follow-up for it after this one,

Sure. That's fine

thanks. I'll open it once this one is merged. there's no code conflict between the two (this PR only touches Sock::WaitMany, the follow-up would change the 5 year value in bitcoin-cli.cpp and the help text), it's more about keeping them apart: this one is tagged for 32.x backport and only fixes the bug, while shortening what 0 means is a behaviour change that shouldn't be backported. if both were open at the same time the "what should 0 mean" discussion would probably end up here too. I'll also check it against #36299 since that touches the same cli timeout code.

winterrdog commented at 10:12 PM on September 29, 2026: contributor

tACK efde1fa215b30fd5f8af70828ff37d4643b63d5e

successfully built and tested on: Windows 10/MSVC 19.51.36257/x86_64

fanquake commented at 9:22 AM on September 30, 2026: member

cc @fjahr @hodlinator

in src/test/sock_tests.cpp:162 in efde1fa215

 154 | @@ -155,6 +155,24 @@ BOOST_AUTO_TEST_CASE(wait)
 155 |      waiter.join();
 156 |  }
 157 |  
 158 | +BOOST_AUTO_TEST_CASE(wait_large_timeout)
 159 | +{
 160 | +    TcpSocketPair socks{};
 161 | +
 162 | +    // bitcoin-cli uses a 5 year timeout for -rpcclienttimeout=0. Start waiting

fjahr commented at 12:36 PM on September 30, 2026:

You are changing that here to be ~25 days so this comment isn't correct.

in src/util/sock.cpp:166 in efde1fa215

 162 | @@ -162,6 +163,10 @@ bool Sock::Wait(std::chrono::milliseconds timeout, Event requested, Event* occur
 163 |  
 164 |  bool Sock::WaitMany(std::chrono::milliseconds timeout, EventsPerSock& events_per_sock) const
 165 |  {
 166 | +    // Very large timeouts break things: poll() only takes an int and select() fails

fjahr commented at 12:38 PM on September 30, 2026:

This comment makes it sound like the problem still persists but the code change here should fix it so this should be worded differently.

fjahr commented at 12:41 PM on September 30, 2026: contributor

Concept ACK

I can reproduce the issue locally (macOS). I think the unit test isn't necessary, a one-line use of -rpcclienttimeout=0 should be enough coverage afaict. That could be placed in interface_bitcoin_cli. py.

kriss39 commented at 6:51 PM on September 30, 2026: contributor

Thanks for the review! Took all three suggestions in 74aad91711: dropped the sock_tests unit test, added a -rpcclienttimeout=0 call to interface_bitcoin_cli.py (it fails on macOS without the cap with "Could not connect to the server" and passes with it), and reworded the comment in Sock::WaitMany. Happy to squash if preferred.

winterrdog commented at 7:38 PM on September 30, 2026: contributor

~~the CI failure herein is independent of the PR changes. it was fixed in #36381. rebasing on current master will resolve the issue~~

EDIT: this is incorrect. refer to the comment below to see why

DrahtBot added the label CI failed on Sep 30, 2026

maflcko commented at 8:25 PM on September 30, 2026: member

the CI failure herein is independent of the PR changes. it was fixed in #36381. rebasing on current master will resolve the issue

No, it is not:

The CI will rebase itself before a run, so a rebase is no different than running the CI again.
Also, the pull you are referring to fixed an issue in the test_maxfeerate test. The CI failure here is in a different line and different function and has a different error message. (https://github.com/bitcoin/bitcoin/actions/runs/36761522744/job/110045003745?pr=36340#step:11:8289)

maflcko commented at 8:30 PM on September 30, 2026: member

Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits

DrahtBot removed the label CI failed on Sep 30, 2026

util: cap Sock::WaitMany timeout

bitcoin-cli turns -rpcclienttimeout=0 into a 5 year timeout and passes
it down to Sock::Wait. On systems without poll() (e.g. macOS and the
BSDs) the wait is done with select(), which fails with EINVAL for
timeouts above 10^8 seconds on macOS. So since the libevent removal in
#34342, `bitcoin-cli -rpcclienttimeout=0 ...` fails on macOS with
"Could not connect to the server". With poll(), the millisecond count
is narrowed to int, so large values can wrap as well.

Cap the timeout at INT_MAX milliseconds (about 24.8 days), which fits
poll() and stays below the 31 days that POSIX requires select() to
accept.

Add a bitcoin-cli call with -rpcclienttimeout=0 to
interface_bitcoin_cli.py. It fails on macOS without the cap.

8dcf90a9b3

kriss39 force-pushed on Sep 30, 2026

kriss39 commented at 8:48 PM on September 30, 2026: contributor

Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits

Squashed, done it

l0rinc commented at 7:00 PM on October 1, 2026: contributor

Concept ACK

fjahr commented at 2:58 PM on October 2, 2026: contributor

ACK 8dcf90a9b320c791f49f78de3b1094f54068e339

DrahtBot requested review from winterrdog on Oct 2, 2026

DrahtBot requested review from l0rinc on Oct 2, 2026

winterrdog commented at 12:02 PM on October 3, 2026: contributor

tested ACK 8dcf90a9b320c791f49f78de3b1094f54068e339

successfully built and tested with clang++-19 on FreeBSD 15.0, targeting x86_64.

when i tested on NetBSD 11.0 and FreeBSD 15.0, i found out that the new test in interface_bitcoin_cli.py passed with or without the fix. seems like it was a macOS-specific bug

kriss39 commented at 4:40 PM on October 3, 2026: contributor

Thanks for testing on the BSDs. Yes, the select() limit that breaks here is macOS-specific (it rejects timeouts above 10^8 s), and FreeBSD/NetBSD accept the 5 year value as your run shows, so on those platforms the test only guards against regressions.

ismaelsadeeq commented at 1:25 AM on October 6, 2026: member

Tested ACK 8dcf90a9b320c791f49f78de3b1094f54068e339

macOS 26.6.2 (25G83), arm64 (Apple M2 Pro, - Xcode 26.1 (17B55), Apple clang 17.0.0, SDK 26.1

<details> <summary>Verified failure before the commit</summary>

2026-10-06T01:04:09.918099Z TestFramework (INFO): PRNG seed is: 1035024185365461830
2026-10-06T01:04:09.973544Z TestFramework (INFO): Initializing test directory /var/folders/dj/d8p8jhd172n7wnq81ryfl6rc0000gn/T/bitcoin_func_test_k0jq636n
2026-10-06T01:04:10.237238Z TestFramework (INFO): Test JSON parameter parsing containing '=' is handled correctly with -named
2026-10-06T01:04:10.780841Z TestFramework (INFO): Compare responses from getblockchaininfo RPC and `bitcoin-cli getblockchaininfo`
2026-10-06T01:04:10.791175Z TestFramework (INFO): Test named arguments
2026-10-06T01:04:10.818231Z TestFramework (INFO): Test that later cli named arguments values silently overwrite earlier ones
2026-10-06T01:04:10.835351Z TestFramework (INFO): Test -stdinrpcpass option
2026-10-06T01:04:11.110782Z TestFramework (INFO): Test -stdin and -stdinrpcpass
2026-10-06T01:04:11.409459Z TestFramework (INFO): Test -rpcclienttimeout=0 (no timeout)
2026-10-06T01:04:11.431430Z TestFramework (ERROR): Called Process failed with stdout='error: Error while attempting to communicate with server 127.0.0.1:17693 (Could not connect to the server)

Make sure the bitcoind server is running and that you are connecting to the correct RPC port.
Use "bitcoin-cli -help" for more info.
'; stderr='None';
Traceback (most recent call last):
  File "/Users/abubakarismail/Desktop/Work/bitcoin-dev/bitcoin/test/functional/test_framework/test_framework.py", line 145, in main
    self.run_test()
    ~~~~~~~~~~~~~^^
  File "/Users/abubakarismail/Desktop/Work/bitcoin-dev/bitcoin/build/test/functional/interface_bitcoin_cli.py", line 149, in run_test
    assert_equal(BLOCKS, self.nodes[0].cli('-rpcclienttimeout=0').getblockcount())
                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/Users/abubakarismail/Desktop/Work/bitcoin-dev/bitcoin/test/functional/test_framework/test_node.py", line 919, in __call__
    return self.cli.send_cli(self.command, *args, **kwargs)
           ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/abubakarismail/Desktop/Work/bitcoin-dev/bitcoin/test/functional/test_framework/test_node.py", line 1006, in send_cli
    raise subprocess.CalledProcessError(returncode, p_args, output=cli_stderr)
subprocess.CalledProcessError: Command '['/Users/abubakarismail/Desktop/Work/bitcoin-dev/bitcoin/build/bin/bitcoin-cli', '-nonamed', '-datadir=/var/folders/dj/d8p8jhd172n7wnq81ryfl6rc0000gn/T/bitcoin_func_test_k0jq636n/node0', '-rpcclienttimeout=30', '-rpcconnect=127.0.0.1', '-rpcport=17693', '-rpcclienttimeout=0', 'getblockcount']' returned non-zero exit status 1.
2026-10-06T01:04:11.485077Z TestFramework (INFO): Not stopping nodes as test failed. The dangling processes will be cleaned up later.
2026-10-06T01:04:11.485232Z TestFramework (WARNING): Not cleaning up dir /var/folders/dj/d8p8jhd172n7wnq81ryfl6rc0000gn/T/bitcoin_func_test_k0jq636n
2026-10-06T01:04:11.485307Z TestFramework (ERROR): Test failed. Test logging available at /var/folders/dj/d8p8jhd172n7wnq81ryfl6rc0000gn/T/bitcoin_func_test_k0jq636n/test_framework.log
2026-10-06T01:04:11.485488Z TestFramework (ERROR):
2026-10-06T01:04:11.485682Z TestFramework (ERROR): Hint: Call /Users/abubakarismail/Desktop/Work/bitcoin-dev/bitcoin/test/functional/combine_logs.py '/var/folders/dj/d8p8jhd172n7wnq81ryfl6rc0000gn/T/bitcoin_func_test_k0jq636n' to consolidate all logs
2026-10-06T01:04:11.485826Z TestFramework (ERROR):
2026-10-06T01:04:11.485879Z TestFramework (ERROR): If this failure happened unexpectedly or intermittently, please file a bug and provide a link or upload of the combined log.
2026-10-06T01:04:11.485971Z TestFramework (ERROR): https://github.com/bitcoin/bitcoin/issues
2026-10-06T01:04:11.486021Z TestFramework (ERROR):
[node 0] Cleaning up leftover process

</details>

<details> <summary>After the commit all tests passed</summary>

2026-10-06T01:09:45.565881Z TestFramework (INFO): PRNG seed is: 3789358713700754495
2026-10-06T01:09:45.621480Z TestFramework (INFO): Initializing test directory /var/folders/dj/d8p8jhd172n7wnq81ryfl6rc0000gn/T/bitcoin_func_test_ii8e7wmf
2026-10-06T01:09:46.648916Z TestFramework (INFO): Test JSON parameter parsing containing '=' is handled correctly with -named
2026-10-06T01:09:47.179721Z TestFramework (INFO): Compare responses from getblockchaininfo RPC and `bitcoin-cli getblockchaininfo`
2026-10-06T01:09:47.189485Z TestFramework (INFO): Test named arguments
2026-10-06T01:09:47.214145Z TestFramework (INFO): Test that later cli named arguments values silently overwrite earlier ones
2026-10-06T01:09:47.230313Z TestFramework (INFO): Test -stdinrpcpass option
2026-10-06T01:09:47.520153Z TestFramework (INFO): Test -stdin and -stdinrpcpass
2026-10-06T01:09:47.827893Z TestFramework (INFO): Test -rpcclienttimeout=0 (no timeout)
2026-10-06T01:09:47.858168Z TestFramework (INFO): Test connecting to a non-existing server
2026-10-06T01:09:47.876925Z TestFramework (INFO): Test handling of invalid ports in rpcconnect
2026-10-06T01:09:47.917017Z TestFramework (INFO): Checking for IPv6
2026-10-06T01:09:47.946937Z TestFramework (INFO): Test handling of invalid ports in rpcport
2026-10-06T01:09:47.977384Z TestFramework (INFO): Test port usage preferences
2026-10-06T01:09:48.035580Z TestFramework (INFO): Test connecting with non-existing RPC cookie file
2026-10-06T01:09:48.313981Z TestFramework (INFO): Test connecting with neither cookie file, nor password
2026-10-06T01:09:48.890021Z TestFramework (INFO): Test connecting with invalid cookie file
2026-10-06T01:09:49.180851Z TestFramework (INFO): Test connecting without RPC cookie file and with password arg
2026-10-06T01:09:49.202789Z TestFramework (INFO): Test -getinfo with arguments fails
2026-10-06T01:09:49.214406Z TestFramework (INFO): Test -getinfo with -color=never does not return ANSI escape codes
2026-10-06T01:09:49.227831Z TestFramework (INFO): Test -getinfo with -color=always returns ANSI escape codes
2026-10-06T01:09:49.239338Z TestFramework (INFO): Test -getinfo with invalid value for -color option
2026-10-06T01:09:49.251072Z TestFramework (INFO): Test -getinfo returns expected network and blockchain info
2026-10-06T01:09:49.593629Z TestFramework (INFO): Test -getinfo and bitcoin-cli return all proxies
2026-10-06T01:09:50.034315Z TestFramework (INFO): Test -getinfo and bitcoin-cli getwalletinfo return expected wallet info
2026-10-06T01:09:50.902411Z TestFramework (INFO): Test -getinfo with multiple wallets and -rpcwallet returns specified wallet balance
2026-10-06T01:09:50.928969Z TestFramework (INFO): Test -getinfo with multiple wallets and -rpcwallet=non-existing-wallet returns no balances
2026-10-06T01:09:50.937207Z TestFramework (INFO): Test -getinfo with multiple wallets returns all loaded wallet names and balances
2026-10-06T01:09:50.957340Z TestFramework (INFO): Test -getinfo after unloading all wallets except a non-default one returns its balance
2026-10-06T01:09:50.966461Z TestFramework (INFO): Test -getinfo -norpcwallet returns the same as -getinfo
2026-10-06T01:09:50.975104Z TestFramework (INFO): Test -getinfo with -rpcwallet=remaining-non-default-wallet returns only its balance
2026-10-06T01:09:50.983503Z TestFramework (INFO): Test -getinfo with -rpcwallet=unloaded wallet returns no balances
2026-10-06T01:09:51.093813Z TestFramework (INFO): Test -generate with no args
2026-10-06T01:09:51.104692Z TestFramework (INFO): Test -generate with bad args
2026-10-06T01:09:51.139444Z TestFramework (INFO): Test -generate with nblocks
2026-10-06T01:09:51.152933Z TestFramework (INFO): Test -generate with nblocks and maxtries
2026-10-06T01:09:51.164655Z TestFramework (INFO): Test -generate -rpcwallet in single-wallet mode
2026-10-06T01:09:51.176059Z TestFramework (INFO): Test -generate -rpcwallet=unloaded wallet raises RPC error
2026-10-06T01:09:51.215891Z TestFramework (INFO): Test -generate -rpcwallet=<filename> raise RPC error
2026-10-06T01:09:51.225160Z TestFramework (INFO): Test -generate -rpcwallet with no args
2026-10-06T01:09:51.235488Z TestFramework (INFO): Test -generate -rpcwallet with bad args
2026-10-06T01:09:51.262271Z TestFramework (INFO): Test -generate -rpcwallet with nblocks
2026-10-06T01:09:51.273166Z TestFramework (INFO): Test -generate -rpcwallet with nblocks and maxtries
2026-10-06T01:09:51.287620Z TestFramework (INFO): Test -generate without -rpcwallet in multiwallet mode raises RPC error
2026-10-06T01:09:51.325395Z TestFramework (INFO): Test -netinfo header and separate local services line
2026-10-06T01:09:51.336206Z TestFramework (INFO): Test -netinfo local services are moved to header if details are requested
2026-10-06T01:09:51.346761Z TestFramework (INFO): Test -rpcid option sets custom JSON-RPC request ID
2026-10-06T01:09:51.356792Z TestFramework (INFO): Test default request logs default id=1
2026-10-06T01:09:51.365802Z TestFramework (INFO): Test that request ids with unsafe characters are sanitized in the log
2026-10-06T01:09:51.376348Z TestFramework (INFO): Test -version with node stopped
2026-10-06T01:09:51.548012Z TestFramework (INFO): Test -rpcwait option successfully waits for RPC connection
2026-10-06T01:09:51.818937Z TestFramework (INFO): Test -rpcwait option waits at most -rpcwaittimeout seconds for startup
2026-10-06T01:09:57.021658Z TestFramework (INFO): Test that only one of -addrinfo, -generate, -getinfo, -netinfo may be specified at a time
2026-10-06T01:09:57.097729Z TestFramework (INFO): Stopping nodes
2026-10-06T01:09:57.098138Z TestFramework (INFO): Cleaning up /var/folders/dj/d8p8jhd172n7wnq81ryfl6rc0000gn/T/bitcoin_func_test_ii8e7wmf on exit
2026-10-06T01:09:57.098287Z TestFramework (INFO): Tests successful

</details>

On Linux this is not an issue at all, since it uses poll() and the test passes both before and after the commit, Tested on NixOS 25.11 , x86_64 (AMD Ryzen 7 7700), clang 19.1.7

pinheadmz approved

pinheadmz commented at 5:22 PM on October 6, 2026: member

ACK 8dcf90a9b320c791f49f78de3b1094f54068e339

Built and tested on macos/arm64. Test fails without the patch and the expected behavior as documented is restored by the patch. There's already been reviewer bike shedding about using nullptr to get a "truly infinite" wait and sounds like that is queued for a follow-up.

This could be merged as-is (already has many approvals) but could also be a bit better:

I think it's ok to keep this limit in Sock and although the only value it will have a practical effect on is -rpcclienttimeout it does technically affect all call sites. I think for that reason it would make sense to mention the cap in the doxygen comment in sock.h for Wait().

We should also probably replace the now-deceptive "5 years" line with the same constant (max_int).

Also I think the PR description mentions a unit test that was factored out and that should probably be updated before merging.

Finally, since we are punting on nullptr/actual no-timeout it should probably be documented in the PR description or a release note that "no timeout" no means "24 days" on all platforms.

<details><summary>Show Signature</summary>

pinheadmz's public key is on openpgp.org

</details>

ismaelsadeeq commented at 5:41 AM on October 7, 2026: member

rfm?

sedited merged this on Oct 7, 2026

sedited closed this on Oct 7, 2026

winterrdog commented at 2:09 PM on October 7, 2026: contributor

reply-to: #36340#pullrequestreview-5432163447

We should also probably replace the now-deceptive "5 years" line with the same constant (max_int).

i agree. std::numeric_limits<int>::max() is fine

kriss39 referenced this in commit b497503376 on Oct 7, 2026

fanquake removed the label Needs Backport (32.x) on Oct 7, 2026

fanquake commented at 4:24 PM on October 7, 2026: member

Backported to 32.x #36427.

fanquake referenced this in commit b2c6f6f027 on Oct 7, 2026