rpc: Add a `-rpcwaittimeout` parameter to limit time spent waiting #21056

cdecker · 2021-02-01T17:34:24Z

Adds a new numeric -rpcwaittimeout that can be used to limit the
time we spend waiting on the RPC server to appear. This is used by
downstream projects to provide a bit of slack when bitcoinds RPC
interface is not available right away.

This makes the -rpcwait argument more useful, since we can now limit
how long we'll ultimately wait, before potentially giving up and reporting
an error to the caller. It was discussed in the context of the BTCPayServer
wanting to have c-lightning wait for the RPC interface to become available
but still have the option of giving up eventually (4355).

I checked with laanwj whether this is already possible (comment), and
whether this would be a welcome change. Initially I intended to repurpose
the (optional) argument to -rpcwait, however I decided against it since it
would potentially break existing configurations, using things like rpcwait=1,
or rpcwait=true (the former would have an unintended short timeout, when
old behavior was to wait indefinitely).

Due to its simplicity I didn't implement a test for it yet, but if that's desired I
can provide one. Test was added during reviews.

jonatack

Concept ACK. Could append a test to the existing -rpcwait coverage at the end of test/functional/interface_bitcoin_cli.py to add coverage.

jonatack · 2021-02-01T19:24:37Z

src/bitcoin-cli.cpp

@@ -712,6 +714,9 @@ static UniValue ConnectAndCallRPC(BaseRequestHandler* rh, const std::string& str
    UniValue response(UniValue::VOBJ);
    // Execute and handle connection failures with -rpcwait.
    const bool fWait = gArgs.GetBoolArg("-rpcwait", false);
+    const int timeout = gArgs.GetArg("-rpcwaittimeout", DEFAULT_WAIT_CLIENT_TIMEOUT);
+    const int64_t deadline = GetTime() + timeout;


I think GetTime is deprecated in favor of GetSystemTimeInSeconds (not mockable) or GetTime<T> (mockable), see src/util.time.h

Ok, amended the use of GetTime with the GetTime<T> version (had to look it up, hopefully I got the right version).

jonatack · 2021-02-01T19:29:44Z

src/bitcoin-cli.cpp

@@ -70,6 +71,7 @@ static void SetupCliArgs(ArgsManager& argsman)
    argsman.AddArg("-rpcport=<port>", strprintf("Connect to JSON-RPC on <port> (default: %u, testnet: %u, signet: %u, regtest: %u)", defaultBaseParams->RPCPort(), testnetBaseParams->RPCPort(), signetBaseParams->RPCPort(), regtestBaseParams->RPCPort()), ArgsManager::ALLOW_ANY | ArgsManager::NETWORK_ONLY, OptionsCategory::OPTIONS);
    argsman.AddArg("-rpcuser=<user>", "Username for JSON-RPC connections", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
    argsman.AddArg("-rpcwait", "Wait for RPC server to start", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
+    argsman.AddArg("-rpcwaittimeout=<n>", strprintf("Timeout in seconds to wait for the RPC server to start, or 0 for no timeout. (default: %d)", DEFAULT_WAIT_CLIENT_TIMEOUT), ArgsManager::ALLOW_INT, OptionsCategory::OPTIONS);


Judging from the PR description you likely thought about this, but could the timeout still be an argument in -rpcwait and only kick in if the value is greater than 1? That would avoid introducing another config option and as a bonus would be shorter to type. IDK what kind of timeout values API clients need.

I'm quite happy to switch it around, but having 1 as a special value is kinda weird as well. I thought I'd go the most cautious route first and see which way wins in the review xD

Fair. Is the real time ever that low anyway? Maybe counting -rpcwait=1 as one second would be fine...I don't have a fast computer and generally run debug builds, so I may see slower times than others, but rpcwait is ~3 seconds for me on signet and much longer on regtest (~10s), testnet (~95s) and mainnet.

I don't expect many users to run into issues if we were to special case -rpcwait=1, but given the "creativity" of users I wouldn't put it past them to use -rpcwait=42 or -rpcwait=31337. Some users seem to see "any value" as a personal challenge 😃

I'd still be in favor of combining rpcwait and rpcwaittimeout, but if we prefer two arguments for this, it may be helpful to mention the relationship to -rpcwait in this description.

jonatack · 2021-02-01T19:30:18Z

src/bitcoin-cli.cpp

@@ -39,6 +39,7 @@ UrlDecodeFn* const URL_DECODE = urlDecode;

 static const char DEFAULT_RPCCONNECT[] = "127.0.0.1";
 static const int DEFAULT_HTTP_CLIENT_TIMEOUT=900;
+static const int DEFAULT_WAIT_CLIENT_TIMEOUT=0;


nit, could be constexpr and apply clang formatting for new code

Had to catch up about constexpr, but good point 👍

theStack · 2021-02-01T22:59:52Z

Concept ACK

laanwj · 2021-02-02T05:49:07Z

Concept ACK

practicalswift · 2021-02-02T12:29:20Z

Concept ACK

cdecker · 2021-02-03T12:19:41Z

Thanks for the reviews and concept ACKs everybody 👍

I'm a bit puzzled by the appveyo failure, which doesn't surface any details related to these changes, is this something my changes broke or was it something with master at the time of the branching?

promag · 2021-02-03T12:29:23Z

Concept ACK, code change looks good to me.

Just noting that effective minimum timeout is 1s, maybe sleep with min(timout, 1s)? An alternative would be to specify attempt count.

cdecker · 2021-02-03T12:36:41Z

Just noting that effective minimum timeout is 1s, maybe sleep with min(timout, 1s)? An alternative would be to specify attempt count.

Excellent point/ The reason I went for the deadline approach was that in between sleeps we are actually attempting to connect over the network, which has its own timeout (DEFAULT_HTTP_CLIENT_TIMEOUT), which would cause drift if we were to just count the attempts instead of using the delta.

Effectively the time we can wait in the worst case is -rpcwaittimeout + DEFAULT_HTTP_CLIENT_TIMEOUT if we happen to start an attempt right before the deadline gets triggered. If we were counting we'd have a maximum of -rpcwaittimeout * (1s + DEFAULT_HTTP_CLIENT_TIMEOUT) , which isn't really the interface I'd feel comfortable using.

jonatack · 2021-02-03T13:33:28Z

I'm a bit puzzled by the appveyo failure, which doesn't surface any details related to these changes, is this something my changes broke or was it something with master at the time of the branching?

Appveyor is a bit flakey ATM, it's probably unrelated.

cdecker · 2021-02-05T11:55:58Z

Rebased on top of master and squashed, let's see if the flake persists.

cdecker · 2021-02-08T11:16:15Z

Yep seems, like CI is happier now ^^

promag

Code review ACK 7dcead4.

nit, could have a release note.

darosior

Concept ACK

Small note too: you should remove the @ from the OP or laanwj will get spammed by all the altcoins merge (and the merge script will refuse it anyways) :)

darosior · 2021-02-10T21:47:27Z

src/bitcoin-cli.cpp

@@ -713,6 +715,9 @@ static UniValue ConnectAndCallRPC(BaseRequestHandler* rh, const std::string& str
    UniValue response(UniValue::VOBJ);
    // Execute and handle connection failures with -rpcwait.
    const bool fWait = gArgs.GetBoolArg("-rpcwait", false);
+    const int timeout = gArgs.GetArg("-rpcwaittimeout", DEFAULT_WAIT_CLIENT_TIMEOUT);
+    const int64_t deadline = GetTime<std::chrono::microseconds>().count() + timeout;


I think you want this to be std::chrono::seconds instead of std::chrono::microseconds, or to change the doc above to mention the parameter is passed in microseconds.

cdecker · 2021-02-15T10:41:50Z

Code review ACK 7dcead4.

nit, could have a release note.

Can you point me to the conventions for release notes? This is my first PR that might need them 🎉

laanwj · 2021-02-15T10:55:26Z

Can you point me to the conventions for release notes? This is my first PR that might need them

I couldn't find anything in CONTRIBUTING.md (this would make sense to add). We prefer to use 'release notes fragments' to avoid introducing merge hotspots. These will be collected before the next major release.

These have a) the broad category (in this case, I guess "RPC client functionality") b) a very brief description (not full documentation!) of the user-visible change.

See for example:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes-18077.md
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes-19776.md

cdecker · 2021-02-15T11:04:07Z

Can you point me to the conventions for release notes? This is my first PR that might need them

I couldn't find anything in CONTRIBUTING.md (this would make sense to add). We prefer to use 'release notes fragments' to avoid introducing merge hotspots. These will be collected before the next major release.

These have a) the broad category (in this case, I guess "RPC client functionality") b) a very brief description (not full documentation!) of the user-visible change.

See for example:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes-18077.md
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes-19776.md

Awesome, thanks. I was expecting something like this to avoid hotspots, and it's way easier than c-lightning's Changelog-in-the-commit-message method 👍

promag · 2021-02-15T11:05:03Z

We have details at https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#release-notes

laanwj · 2021-02-15T11:10:28Z

We have details at https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#release-notes

Oh great! I somehow couldn't find this (I did grep for a few things). Might make sense to link to this from CONTRIBUTING.md.

cdecker · 2021-02-16T14:10:05Z

Added preliminary release notes in a new file, and fixed up the units in the GetTime<T> template as well as the unit of the sleep call. Let me know if the release notes are not in the desired format, and I'll fix them up asap.

jonatack

A few comments below. Haven't checked, but ISTM the logic could use std::chrono throughout rather than converting values back to integers. A functional test verifying the timeout works correctly and a specific error type is raised might be a good idea.

jonatack · 2021-02-16T15:29:41Z

doc/release-notes-21056.md

+
+- The new `-rpcwaittimeout` argument to `bitcoin-cli` sets the timeout
+  in seconds to use with `-rpcwait`. If the timeout expires
+  `bitcoin-cli` will report a failure. (#21056)


Among the current headers in doc/release-notes.md, "New settings" might be the closest, but I'm not sure. There doesn't seem to be a CLI header. Suggestion follows, feel free to ignore.

-RPC client functionality ------------------------- +New settings +------------ -- The new `-rpcwaittimeout` argument to `bitcoin-cli` sets the timeout - in seconds to use with `-rpcwait`. If the timeout expires +- A new `-rpcwaittimeout` argument to `bitcoin-cli` sets the timeout + in seconds to use with `-rpcwait`. If the timeout expires, `bitcoin-cli` will report a failure. (#21056)

I don't know if that header is better. As a compromise "New bitcoin-cli settings" maybe?

I do think it's important to keep mentions of server and other tools's command line arguments separated. Then again, all of this can be organized when merging the fragments—it's not an automatic process.

Yes, "New bitcoin-cli settings" seems better to me, too. Though as mentioned in #21056 (comment), if we add the argument to the existing -rpcwait= (as a CLI setting intended for human manual use rather than by client software, ISTM it may be less subject to API constraints and would be less verbose than -rpcwait -rpcwaittimeout=), it could be "Updated bitcoin-cli settings".

jonatack · 2021-02-16T15:36:18Z

src/bitcoin-cli.cpp

@@ -70,6 +71,7 @@ static void SetupCliArgs(ArgsManager& argsman)
    argsman.AddArg("-rpcport=<port>", strprintf("Connect to JSON-RPC on <port> (default: %u, testnet: %u, signet: %u, regtest: %u)", defaultBaseParams->RPCPort(), testnetBaseParams->RPCPort(), signetBaseParams->RPCPort(), regtestBaseParams->RPCPort()), ArgsManager::ALLOW_ANY | ArgsManager::NETWORK_ONLY, OptionsCategory::OPTIONS);
    argsman.AddArg("-rpcuser=<user>", "Username for JSON-RPC connections", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
    argsman.AddArg("-rpcwait", "Wait for RPC server to start", ArgsManager::ALLOW_ANY, OptionsCategory::OPTIONS);
+    argsman.AddArg("-rpcwaittimeout=<n>", strprintf("Timeout in seconds to wait for the RPC server to start, or 0 for no timeout. (default: %d)", DEFAULT_WAIT_CLIENT_TIMEOUT), ArgsManager::ALLOW_INT, OptionsCategory::OPTIONS);


I'd still be in favor of combining rpcwait and rpcwaittimeout, but if we prefer two arguments for this, it may be helpful to mention the relationship to -rpcwait in this description.

jonatack · 2021-02-16T15:44:58Z

src/bitcoin-cli.cpp

-            if (fWait) {
-                UninterruptibleSleep(std::chrono::milliseconds{1000});
+            const int64_t now = GetTime<std::chrono::seconds>().count();
+            if (fWait && (timeout == 0 || now < deadline)) {


The error I'm seeing is a bit confusing. It would be good to raise a specific error for the timeout value exceeded.

$ bitcoind -regtest -daemon ; bitcoin-cli -regtest -rpcwait -rpcwaittimeout=3 -getinfo Bitcoin Core starting error: server in warmup

luke-jr

utACK, but I think actual software shouldn't be using bitcoin-cli at all...

laanwj · 2021-02-25T20:23:29Z

utACK, but I think actual software shouldn't be using bitcoin-cli at all...

For what it's worth I agree with @luke-jr here. Never really understood why lightningd doesn't use the RPC API directly. It's generally the more stable way, less moving parts, less potential ambiguity in input arguments. But it's an aside of course and off topic here.

cdecker · 2021-02-26T10:16:12Z

For what it's worth I agree with @luke-jr here. Never really understood why lightningd doesn't use the RPC API directly. It's generally the more stable way, less moving parts, less potential ambiguity in input arguments. But it's an aside of course and off topic here.

Not trying to make this a lightningd specific proposal, but since it was brought up I'll try to reconstruct the rationale at the time.

It was/is easier to call out to an existing program that includes the logic for authentication, error handling and timeouts than to implement it from scratch on top of out io library which doesn't have good http support (this is likely self-inflicted, but it's what we've got and it's working well for us so far). Authentication here being the big win, since if you have bitcoin-cli working you don't have to do anything to configure lightningd to be able to talk to bitcoind (no need to handle cookie auth, user/pass auth, binding and connecting, no need to implement TLS). If we had implemented all these things we'd likely have ended up replicating all the functionality bitcoin-cli already has, which didn't seem like a good investment of time given the already huge amount of work to be done.

Are there downsides of calling out to bitcoin-cli? Sure. Will we eventually end up replacing it with an internal implementation? Maybe. Is it working well as it is now? I think so 😉

That being said, I'm sure we're not the only ones that could use a wait timeout (thinking primarily of scripts and operations).

laanwj · 2021-02-26T16:15:22Z

Are there downsides of calling out to bitcoin-cli? Sure. Will we eventually end up replacing it with an internal implementation? Maybe. Is it working well as it is now? I think so

I guess it's mostly down to personal preference, I prefer to use APIs directly, calling out to external programs reminds me of shell scripts which always are very environment-dependent. One concrete case is that bitcoin RPC might be forwarded from another container. Right now it's necessary to copy bitcoin-cli to the container hosting c-lightning.

Also as bitcoin-cli is aimed at human users, it has some client-side processing for arguments—some arguments are parsed as JSON others string-ized. Sending JSON directly is more "pure". Due to this added "moving part" I would personally prefer to avoid it from robust software.

Also accessing the API directly gives you full control over things such as timeouts. No need to wait for PRs to be merged here and then part of a release so that users have it 😄 JSONRPC handling is straightforward if you already have JSON for your own APIs.

It was/is easier to call out to an existing program that includes the logic for authentication

For authentication—I'd somewhat agree, but we don't do anything complex such as HMAC or challenge/response. The only available authentication mechanism is HTTP basic authentication with a) send $DATADIR/.cookie as user/password or b) manually provide user/password.

no need to implement TLS

There hasn't been TLS support in bitcoin-cli for years.

Sorry for derailing this further. Again, this is not meant as criticism on this change nor on lightningd (and I'm not volunteering to make a patch to change this). As you say, it works 🤷‍♀️

cdecker · 2021-03-08T13:19:40Z

Reworded the release notes as proposed by @jonatack, and rebased on top of master.

Open questions are:

Add a specific error message pointing towards a timeout if we get something like RPC warmup
- Pointed out here
- I think passing through the error is correct here, and not amend it since the timeout is merely retrying a failing attempt and eventually we give up passing through the cause. If we were to customize the error we could end up hiding the underlying cause for the failure (timeout ok, but what caused the timeout to fail ultimately?)
Instead of adding a new command line option in the form of -rpcwaittimeout, merge it instead with -rpcwait, redefining the semantics of the value. See above for discussion but here's a summary:
- Pro: merging avoids adding a new option, making the expression more concise
- Con: users may have scripts and utilities that use -rpcwait=1 to opt into the waiting, but with the new semantics we'd just wait for 1 second. Also suddenly things like -rpcwait=true would be invalid or we'd require workarounds mapping true, on etc to 0.

Anything I'm missing?

promag

Tested ACK 4840dee.

As far as I can see the only unresolved thing in this PR is the discussion about whether to reuse -rpcwait and redefine the argument to be the timeout in seconds, or whether the current addition of a new flag is preferrable.

I think current approach is fine otherwise how would the user disable waiting - -rpcwait=0 is disable or wait forever?

@cdecker you can update OP now that there is a test.

promag · 2021-04-22T08:06:07Z

test/functional/interface_bitcoin_cli.py

+        self.log.info("Test -rpcwait option waits at most -rpcwaittimeout seconds for startup")
+        self.stop_node(0)  # stop the node so we time out
+        assert_raises_process_error(1, "Could not connect to the server", self.nodes[0].cli('-rpcwait', '-rpcwaittimeout=5').echo)
+


nit, could check elapsed time is >= to 5s.

Added check using assert_greater_than_or_equal and had to import time but that should work ok.

This should be assert_greater_than_or_equal(time.time(), start_time + 5).

promag · 2021-04-22T09:05:15Z

src/bitcoin-cli.cpp

@@ -738,6 +740,9 @@ static UniValue ConnectAndCallRPC(BaseRequestHandler* rh, const std::string& str
    UniValue response(UniValue::VOBJ);
    // Execute and handle connection failures with -rpcwait.
    const bool fWait = gArgs.GetBoolArg("-rpcwait", false);
+    const int timeout = gArgs.GetArg("-rpcwaittimeout", DEFAULT_WAIT_CLIENT_TIMEOUT);


nit, is it fine to accept <0? A negative value is same as -rpcwait=false.

I think so, the alternative would be to throw an error, but that might be a bit much.

promag · 2021-04-22T09:08:50Z

src/bitcoin-cli.cpp

-                UninterruptibleSleep(std::chrono::milliseconds{1000});
+        } catch (const CConnectionFailed& e) {
+            const int64_t now = GetTime<std::chrono::seconds>().count();
+            if (fWait && (timeout == 0 || now < deadline)) {


Maybe timeout <= 0 - zero or negative means no timeout.

Amended the == to become <= 👍

DrahtBot · 2021-05-02T18:00:35Z

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

Conflicts

No conflicts as of last run.

cdecker · 2021-05-11T09:03:53Z

Rebased on top of master, addressed @promag's feedback and amended OP to mention the tests that are now included.

promag · 2021-05-11T17:44:24Z

@cdecker I think you forgot to autosquash?

cdecker · 2021-05-11T19:47:13Z

Sorry, used to the c-lightning workflow where we keep fixups to show how things were addressed. Will squash as soon as I wake up 🙂

Adds a new numeric `-rpcwaittimeout` that can be used to limit the time we spend waiting on the RPC server to appear. This is used by downstream projects to provide a bit of slack when `bitcoind`s RPC interface is not available right away.

@laanwj

As proposed by @laanwj the error message is now prefixed with the "timeout on transient error:" prefix, to explain why the error is suddenly considered terminal.

cdecker · 2021-06-03T09:23:33Z

Rebased on top of master

promag

Tested ACK 5685cdc but the test needs to be fixed.

promag · 2021-06-03T10:05:49Z

test/functional/interface_bitcoin_cli.py

+        self.log.info("Test -rpcwait option waits at most -rpcwaittimeout seconds for startup")
+        self.stop_node(0)  # stop the node so we time out
+        assert_raises_process_error(1, "Could not connect to the server", self.nodes[0].cli('-rpcwait', '-rpcwaittimeout=5').echo)
+


This should be assert_greater_than_or_equal(time.time(), start_time + 5).

@jonatack

Suggested-by: Jon Atack <@jonatack>

promag

ACK b9e76f1.

cdecker · 2021-06-04T10:27:31Z

Tested ACK 5685cdc but the test needs to be fixed.

Yep, I switched the arguments around apparently 😉

cdecker · 2021-06-21T09:54:13Z

Is this good in its current state or does something need to be addressed? Probably not the highest priority issue, but would love to remove it from my watchlist, e.g., by merging it 😉

laanwj · 2021-06-21T10:58:30Z

Code review ACK b9e76f1

…me sp…

Adds a new numeric `-rpcwaittimeout` that can be used to limit the time we spend waiting on the RPC server to appear. This is used by downstream projects to provide a bit of slack when `bitcoind`s RPC interface is not available right away. Github-Pull: bitcoin#21056 Rebased-From: a7fcc8e

@laanwj

As proposed by @laanwj the error message is now prefixed with the "timeout on transient error:" prefix, to explain why the error is suddenly considered terminal. Github-Pull: bitcoin#21056 Rebased-From: f76cb10

@jonatack

Suggested-by: Jon Atack <@jonatack> Github-Pull: bitcoin#21056 Rebased-From: b9e76f1

cdecker force-pushed the rpcwait-timeout branch from c76465d to 7f19f5f Compare February 1, 2021 18:26

DrahtBot added the RPC/REST/ZMQ label Feb 1, 2021

jonatack reviewed Feb 1, 2021

View reviewed changes

cdecker force-pushed the rpcwait-timeout branch from cb8436f to 9d2a38a Compare February 5, 2021 11:55

cdecker force-pushed the rpcwait-timeout branch from 9d2a38a to 7dcead4 Compare February 5, 2021 11:56

promag reviewed Feb 8, 2021

View reviewed changes

darosior suggested changes Feb 10, 2021

View reviewed changes

cdecker force-pushed the rpcwait-timeout branch from 7dcead4 to d373793 Compare February 16, 2021 14:08

jonatack reviewed Feb 16, 2021

View reviewed changes

luke-jr approved these changes Feb 23, 2021

View reviewed changes

cdecker force-pushed the rpcwait-timeout branch from d373793 to 2d8cd2d Compare March 8, 2021 13:12

promag reviewed Apr 22, 2021

View reviewed changes

DrahtBot mentioned this pull request May 2, 2021

cli: Improve -getinfo return format #21832

Merged

cdecker force-pushed the rpcwait-timeout branch from 4840dee to 29a9c9f Compare May 11, 2021 09:02

cdecker force-pushed the rpcwait-timeout branch from 29a9c9f to 2003191 Compare May 14, 2021 17:36

cdecker added 3 commits June 3, 2021 11:23

doc: Add release notes for the -rpcwaittimeout cli parameter

c490e17

rpc: Prefix rpcwaittimeout error with details on its nature

f76cb10

As proposed by @laanwj the error message is now prefixed with the "timeout on transient error:" prefix, to explain why the error is suddenly considered terminal.

cdecker force-pushed the rpcwait-timeout branch from 2003191 to 5685cdc Compare June 3, 2021 09:23

promag reviewed Jun 3, 2021

View reviewed changes

rpc: Add test for -rpcwaittimeout

b9e76f1

Suggested-by: Jon Atack <@jonatack>

cdecker force-pushed the rpcwait-timeout branch from 5685cdc to b9e76f1 Compare June 3, 2021 12:49

promag reviewed Jun 3, 2021

View reviewed changes

maflcko added the Utils/log/libs label Jun 21, 2021

laanwj merged commit 6556da7 into bitcoin:master Jun 21, 2021

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Jun 24, 2021

Merge bitcoin#21056: rpc: Add a -rpcwaittimeout parameter to limit ti…

448f334

…me sp…

cdecker deleted the rpcwait-timeout branch June 24, 2021 12:35

luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Jun 27, 2021

rpc: Add test for -rpcwaittimeout

ec996d1

Suggested-by: Jon Atack <@jonatack> Github-Pull: bitcoin#21056 Rebased-From: b9e76f1

barton2526 mentioned this pull request Sep 22, 2021

Feature Request: Add a -rpcwaittimeout parameter to limit time spent waiting gridcoin-community/Gridcoin-Research#2346

Closed

gwillen pushed a commit to ElementsProject/elements that referenced this pull request Jun 1, 2022

Merge 6556da7 into merged_master (Bitcoin PR bitcoin/bitcoin#21056)

a83d259

bitcoin locked as resolved and limited conversation to collaborators Aug 16, 2022

rpc: Add a -rpcwaittimeout parameter to limit time spent waiting #21056

rpc: Add a -rpcwaittimeout parameter to limit time spent waiting #21056

Conversation

cdecker commented Feb 1, 2021 • edited Loading

jonatack left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonatack Feb 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jonatack Feb 1, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

theStack commented Feb 1, 2021

laanwj commented Feb 2, 2021

practicalswift commented Feb 2, 2021

cdecker commented Feb 3, 2021

promag commented Feb 3, 2021

cdecker commented Feb 3, 2021

jonatack commented Feb 3, 2021

cdecker commented Feb 5, 2021 • edited Loading

cdecker commented Feb 8, 2021

promag left a comment

Choose a reason for hiding this comment

darosior left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdecker commented Feb 15, 2021

laanwj commented Feb 15, 2021 • edited Loading

cdecker commented Feb 15, 2021

promag commented Feb 15, 2021

laanwj commented Feb 15, 2021

cdecker commented Feb 16, 2021

jonatack left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luke-jr left a comment

Choose a reason for hiding this comment

laanwj commented Feb 25, 2021

cdecker commented Feb 26, 2021

laanwj commented Feb 26, 2021

cdecker commented Mar 8, 2021

promag left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdecker May 11, 2021 • edited Loading

Choose a reason for hiding this comment

DrahtBot commented May 2, 2021 • edited Loading

Conflicts

cdecker commented May 11, 2021

promag commented May 11, 2021

cdecker commented May 11, 2021

cdecker commented Jun 3, 2021

promag left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

promag left a comment

Choose a reason for hiding this comment

cdecker commented Jun 4, 2021

cdecker commented Jun 21, 2021

laanwj commented Jun 21, 2021

rpc: Add a `-rpcwaittimeout` parameter to limit time spent waiting #21056

rpc: Add a `-rpcwaittimeout` parameter to limit time spent waiting #21056

cdecker commented Feb 1, 2021 •

edited

Loading

jonatack Feb 1, 2021 •

edited

Loading

jonatack Feb 1, 2021 •

edited

Loading

cdecker commented Feb 5, 2021 •

edited

Loading

laanwj commented Feb 15, 2021 •

edited

Loading

jonatack left a comment •

edited

Loading

cdecker May 11, 2021 •

edited

Loading

DrahtBot commented May 2, 2021 •

edited

Loading