Remove g_rpc_node global

ryanofsky commented at 4:11 pm on April 22, 2020: member

This PR removes the g_rpc_node global, to get same benefits we see removing other globals and make RPC code more testable, modular, and reusable.

This uses a hybrid of the approaches suggested in #17548. Instead of using std::any, which isn’t available in c++11, or void*, which isn’t type safe, it uses a small new util::Ref helper class, which acts like a simplified std::any that only holds references, not values.

Motivation for writing this was to provide an simpler alternative to #18647 by Harris Brakmić (brakmic) which avoids some shortcomings of that PR (https://github.com/bitcoin/bitcoin/pull/18647#issuecomment-617878826)

DrahtBot added the label Build system on Apr 22, 2020

DrahtBot added the label Mining on Apr 22, 2020

DrahtBot added the label RPC/REST/ZMQ on Apr 22, 2020

DrahtBot added the label Tests on Apr 22, 2020

DrahtBot added the label Utils/log/libs on Apr 22, 2020

DrahtBot added the label Wallet on Apr 22, 2020

MarcoFalke removed the label Build system on Apr 22, 2020

MarcoFalke removed the label Mining on Apr 22, 2020

MarcoFalke removed the label Tests on Apr 22, 2020

MarcoFalke removed the label Utils/log/libs on Apr 22, 2020

MarcoFalke removed the label Wallet on Apr 22, 2020

MarcoFalke added the label Refactoring on Apr 22, 2020

ryanofsky force-pushed on Apr 22, 2020

MarcoFalke commented at 4:26 pm on April 22, 2020: member

Instead […] void*, which isn’t type safe, it uses a small new util::Ref

Why not NodeContext*? That might seem like a layer violation reading the source code, but practically it does the same and the diff would be smaller.

ryanofsky commented at 4:49 pm on April 22, 2020: member

Instead […] void*, which isn’t type safe, it uses a small new util::Ref

Why not NodeContext*? That might seem like a layer violation reading the source code, but practically it does the same and the diff would be smaller.

This would allow only allow dropping the first commit. The later commits would look basically the same but with s/util::Ref/NodeContext/.

The practical reason I don’t want to do this is I want to the be able to use the RPC server outside the node process. E.g. start a multiprocess wallet process and have it listen for wallet RPC requests. Maybe add more offline wallet support and be able to have wallet-tool respond to RPCs like listtransactions. In these cases, wallet code can’t link against src/node/context.cpp and NodeContext is useless for passing wallet state (aside from just looking strange).

Also, RPC code in rpc/server and httprpc is mostly pretty generic and not bitcoin specific and personally I think it would be a shame to see bitcoin types leak into it.

promag commented at 5:05 pm on April 22, 2020: member

From #18647 (comment)

Wallet RPC methods shouldn’t have access to NodeContext. At some point we should have WalletContext struct that will hold things like vpwallets and let us get rid of wallet globals, and it would make sense for wallet RPC methods to have access to this. That is why suggestion from #17548 was to just add a new member to JSONRPCRequest that could hold a generic context, not something tied to the wallet or node. Other advantage of using JSONRPCRequest is that you dont’ have to change RPC method signatures.

How would you implement this? Make context a map<string, any>? And do context["node"].Has<NodeContext>()?

practicalswift commented at 5:30 pm on April 22, 2020: contributor

Concept ACK

Very happy to see g_rpc_node go!

Thanks for the great architectural work you are doing.

ryanofsky commented at 5:48 pm on April 22, 2020: member

How would you implement this? Make context a map<string, any>? And do context["node"].Has<NodeContext>()?

No need for multiple contexts in the same request. interfaces::WalletClientImpl can just pass an different context to wallet RPC methods. Passing an interfaces::Chain reference would be sufficient enough for loadwallet / createwallet. But I actually want to introduce a WalletContext struct in src/wallet/context.h analagous to the NodeContext struct in src/node/context.h which would hold things like the Chain interface pointer and vpwallets vector.

ryanofsky commented at 5:58 pm on April 22, 2020: member

Actually @promag, it is a little clumsier than I thought. I should change this PR to pass context to rpc method register calls instead of the StartHTTPRPC call to make this more future-proof (should still be an improvement as is)

ryanofsky force-pushed on Apr 22, 2020

DrahtBot commented at 7:37 pm on April 22, 2020: member

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

#19028 (test: Set -logthreadnames in unit tests by MarcoFalke)
#19011 (Reduce cs_main lock accumulation during GUI startup by jonasschnelli)
#18991 (Cache responses to GETADDR to prevent topology leaks by naumenkogs)
#18698 (Make g_chainman internal to validation by MarcoFalke)
#18531 (rpc: Assert that RPCArg names are equal to CRPCCommand ones by MarcoFalke)
#17356 (RPC: Internal named params by luke-jr)
#13389 (Utils and libraries: Fix #13371 - move umask operation earlier in AppInit() by n2yen)
#12674 (RPC: Support addnode onetry without making the connection priviliged by luke-jr)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

in src/rpc/blockchain.h:53 in fe333744b7 outdated

54-//! RPC methods. Due to limitations of the RPC framework, there's currently no
55-//! direct way to pass in state to RPC methods without globals.
56-extern NodeContext* g_rpc_node;
57-
58-CTxMemPool& EnsureMemPool();
59+NodeContext& EnsureNodeContext(const util::Ref& context);

promag commented at 0:45 am on April 23, 2020:

Have you considered EnsureNodeContext(const JSONRPCRequest& req) instead? Same for EnsureMemPool. Could avoid forward declaration above.

ryanofsky commented at 7:27 pm on April 27, 2020:

re: #18740 (review)

Have you considered EnsureNodeContext(const JSONRPCRequest& req) instead? Same for EnsureMemPool. Could avoid forward declaration above.

Probably considered it, but I don’t like this style (along lines of c++ koan https://www.youtube.com/watch?v=Zx_Tjp9WIII&t=15m07s)

promag commented at 0:46 am on April 23, 2020: member

Concept ACK.

DrahtBot added the label Needs rebase on Apr 23, 2020

ryanofsky force-pushed on Apr 23, 2020

DrahtBot removed the label Needs rebase on Apr 23, 2020

in src/rest.cpp:613 in 41d5d65159 outdated

609@@ -610,7 +610,7 @@ static bool rest_blockhash_by_height(const util::Ref& context, HTTPRequest* req,
610     std::string height_str;
611     const RetFormat rf = ParseDataFormat(height_str, str_uri_part);
612 
613-    int32_t blockheight;
614+    int32_t blockheight = 0;

MarcoFalke commented at 6:18 pm on April 24, 2020:

Heh, nice find. Maybe split this up as a separate pull request, since it seems unrelated to the changes here?

ryanofsky commented at 7:08 pm on April 27, 2020:

re: #18740 (review)

Maybe split this up as a separate pull request, since it seems unrelated to the changes here?

Yes it should be basically be unrelated. I created #18785, but am also keeping the commit here for now, since it does seem to be needed to avoid travis failing with the other changes here https://travis-ci.org/github/bitcoin/bitcoin/jobs/678453061#L7157

ryanofsky renamed this:
~~Remove g_rpc_node global (alternative to #18647)~~
Remove g_rpc_node global
on Apr 27, 2020

ryanofsky commented at 7:41 pm on April 27, 2020: member

Rebased 0708140ceee683e4d6288f4ca6616118e69218dd -> 0d84b1a3a7238ca171e7494904dc0c221b91edc2 (pr/frpc.1 -> pr/frpc.2, compare) to match pr base, also fixed ref clear method Updated 0d84b1a3a7238ca171e7494904dc0c221b91edc2 -> fe333744b72c11030e5a06e904ba44cea167117b (pr/frpc.2 -> pr/frpc.3, compare) adding ref.h to makefile to fix travis errors https://travis-ci.org/github/bitcoin/bitcoin/builds/678246736 Rebased fe333744b72c11030e5a06e904ba44cea167117b -> 5f260284e059504cc6f93dc575054e526470f181 (pr/frpc.3 -> pr/frpc.4, compare) with scope fix and rebase due to conflict with #18671 Added 1 commits 5f260284e059504cc6f93dc575054e526470f181 -> 41d5d651594c6c939add7a58b7e30c97dccdf24a (pr/frpc.4 -> pr/frpc.5, compare) to fix valgrind false positive https://travis-ci.org/github/bitcoin/bitcoin/jobs/678453061#L7157

MarcoFalke referenced this in commit ecca2ea1d5 on Apr 29, 2020

DrahtBot added the label Needs rebase on Apr 29, 2020

sidhujag referenced this in commit 7e91f6db54 on Apr 29, 2020

ryanofsky force-pushed on Apr 29, 2020

ryanofsky commented at 5:20 pm on April 29, 2020: member

Rebased 41d5d651594c6c939add7a58b7e30c97dccdf24a -> 02aa19a8b1a2e7e6b2293ae8512f7c606ca58345 (pr/frpc.5 -> pr/frpc.6, compare) due to conflict with #18785

DrahtBot removed the label Needs rebase on Apr 29, 2020

brakmic commented at 12:03 pm on May 1, 2020: contributor

ACK 02aa19a8b1a2e7e6b2293ae8512f7c606ca58345

Built, run and done some manual RPC testing on macOS Catalina 10.15.4

DrahtBot added the label Needs rebase on May 4, 2020

ryanofsky force-pushed on May 4, 2020

ryanofsky commented at 6:29 pm on May 4, 2020: member

Rebased 02aa19a8b1a2e7e6b2293ae8512f7c606ca58345 -> 1be6bad7c044981faea55c76730a07eb95c2fd9f (pr/frpc.6 -> pr/frpc.7, compare) due to conflict with #18699

DrahtBot removed the label Needs rebase on May 4, 2020

ryanofsky commented at 4:55 am on May 5, 2020: member

Travis error appears to be unrelated “

mkdir: cannot create directory ‘/home/travis/build/bitcoin/bitcoin/ci/scratch’: No space left on device

” in s390x native BE build https://travis-ci.org/github/bitcoin/bitcoin/jobs/683061500#L336. It’s reported in #18868

DrahtBot added the label Needs rebase on May 8, 2020

Add util::Ref class as temporary alternative for c++17 std::any

This commit does not change behavior

691c817b34

refactor: Pass NodeContext to RPC and REST methods through util::Ref

This commit does not change behavior

6fca33b2ed

scripted-diff: Remove g_rpc_node references

This commit does not change behavior

-BEGIN VERIFY SCRIPT-
git grep -l g_rpc_node | xargs sed -i 's/g_rpc_node->/node./g'
-END VERIFY SCRIPT-

ccb5059ee8

refactor: Remove g_rpc_node global

This commit does not change behavior

b3f7f375ef

ryanofsky force-pushed on May 13, 2020

ryanofsky commented at 10:10 pm on May 13, 2020: member

Rebased 1be6bad7c044981faea55c76730a07eb95c2fd9f -> c13af197ce473769303c3bf1bcb38658c5f8de41 (pr/frpc.7 -> pr/frpc.8, compare) due to conflict with #16224

DrahtBot removed the label Needs rebase on May 13, 2020

promag commented at 8:24 am on May 19, 2020: member

Code review ACK c13af197ce473769303c3bf1bcb38658c5f8de41.

ajtowns commented at 8:24 am on May 19, 2020: member

I should change this PR to pass context to rpc method register calls

I found the std::any versus explicit NodeContext tradeoff confusing, but I think this makes sense of it. With a node/wallet/mempool/whatever context passed to the rpc register calls, this means

the RPC infra (server, json request) doesn’t need to know about bitcoin structures at all
the RPC command can just grab its needed context directly, and there doesn’t need to be a struct with pointers to all the different parts that might or might not be available, which will maybe make it easier to split the different contexts into separate programs one day
the RPC server can give an error immediately for RPC commands where the context isn’t available (I guess it’d be “command not found” since it wouldn’t have been registered in the first place)

So, Approach ACK. Planning on updating this pr with the register changes, or doing that later?

ryanofsky commented at 11:49 am on May 19, 2020: member

So, Approach ACK. Planning on updating this pr with the register changes, or doing that later?

Was planning on doing it in a followup PR removing g_rpc_chain

in src/rpc/blockchain.cpp:561 in c13af197ce outdated

557@@ -549,7 +558,7 @@ static UniValue getmempoolancestors(const JSONRPCRequest& request)
558 
559     uint256 hash = ParseHashV(request.params[0], "parameter 1");
560 
561-    const CTxMemPool& mempool = EnsureMemPool();
562+    CTxMemPool& mempool = EnsureMemPool(request.context);

MarcoFalke commented at 11:51 am on May 19, 2020:

:eyes:

ryanofsky commented at 9:40 pm on May 20, 2020:

In commit “refactor: Pass NodeContext to RPC and REST methods through util::Ref” (28941409ac80fe6f8216b4f8fa940b31c270133b)

re: #18740 (review)

:eyes:

Good catch! Added const

in src/test/ref_tests.cpp:26 in d8c253f26e outdated

17+    ref.Set(value);
18+    BOOST_CHECK(ref.Has<int>());
19+    BOOST_CHECK_EQUAL(ref.Get<int>(), 5);
20+    ++ref.Get<int>();
21+    BOOST_CHECK_EQUAL(ref.Get<int>(), 6);
22+    BOOST_CHECK(!ref.Has<bool>());

MarcoFalke commented at 3:01 pm on May 19, 2020:

in the commit that adds ref: Could check that each is an alias for the other? Right now ref could actually be a copy and the test wouldn’t fail.

 0diff --git a/src/test/ref_tests.cpp b/src/test/ref_tests.cpp
 1index ef96a0042a..0ec0799fbc 100644
 2--- a/src/test/ref_tests.cpp
 3+++ b/src/test/ref_tests.cpp
 4@@ -19,6 +19,10 @@ BOOST_AUTO_TEST_CASE(ref_test)
 5     BOOST_CHECK_EQUAL(ref.Get<int>(), 5);
 6     ++ref.Get<int>();
 7     BOOST_CHECK_EQUAL(ref.Get<int>(), 6);
 8+    BOOST_CHECK_EQUAL(value, 6);
 9+    ++value;
10+    BOOST_CHECK_EQUAL(value, 7);
11+    BOOST_CHECK_EQUAL(ref.Get<int>(), 7);
12     BOOST_CHECK(!ref.Has<bool>());
13     BOOST_CHECK_THROW(ref.Get<bool>(), NonFatalCheckError);
14     ref.Clear();

ryanofsky commented at 9:44 pm on May 20, 2020:

In commit “Add util::Ref class as temporary alternative for c++17 std::any” (d8c253f26e1dee43e855f376be3f8c204b23ca50)

re: #18740 (review)

in the commit that adds ref: Could check that each is an alias for the other? Right now ref could actually be a copy and the test wouldn’t fail.

Nice, added suggested checks

MarcoFalke approved

MarcoFalke commented at 3:18 pm on May 19, 2020: member

ACK c13af197ce473769303c3bf1bcb38658c5f8de41 🖋

Signature:

 0-----BEGIN PGP SIGNED MESSAGE-----
 1Hash: SHA512
 2
 3ACK c13af197ce473769303c3bf1bcb38658c5f8de41 🖋
 4-----BEGIN PGP SIGNATURE-----
 5
 6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
 7pUinRwwAkHWlUKKhw3GzOtBTqDhsNMOPj4xwTRNK2IwJujWN/z7nf7bqQLtPBEGw
 87/wtrfXP8azfrGTqBmGTEqRxYjH0HiB8q0qhZvCW+oKGOvUIN1SUPLf9Dumj8oFd
 9HdMIo6IVJmj9weolegQxWNJ7z55E3M7ZblMnKO9pYZqGWjs/Mj2il+Aza0/UjYN1
10HHQX0E8CqZSM08zDJelpkg9qKp0TacEvbJjb2SPirhd9YvxeYIDRhX6Axfdw+rJR
110ujuMTrXuJTJ2fkLhZa6mRzSVDEB/NLqgVQKou1f18epfljFq6xi/1+gFYnro21A
12Jy24DqiB5Jq2kTvox2sgLa3j66E9xdiOh5OKYEi67BjENCZC2lqpKybi0p2P1yP5
13S3MRaFiU1xjShXf8lyV8EUpEZDlj3bZO+zP0x3ox6qxu6vGQzOf+lbUMNQKgyOTJ
14wnBVgW05G7qUGZhUZGoKWf7w2MII/IV6nNWKg/CqAO8g7zjU0rOqlwPhIcYmFQ7J
15bRC2QBGP
16=68aI
17-----END PGP SIGNATURE-----

Timestamp of file with hash 29eb95433107a5581e173c806df9747dec6d545006ccc3f9f225e8cf38bbd914 -

ryanofsky force-pushed on May 20, 2020

ryanofsky commented at 10:00 pm on May 20, 2020: member

Thanks for the review! Updated with suggested changes

Updated c13af197ce473769303c3bf1bcb38658c5f8de41 -> b3f7f375efb9a9ca9a7a4f2caf41fe3df2262520 (pr/frpc.8 -> pr/frpc.9, compare)

in src/util/ref.h:17 in 691c817b34 outdated

12+namespace util {
13+
14+/**
15+ * Type-safe dynamic reference.
16+ *
17+ * This implements a small subset of the functionality in C++17's std::any

ajtowns commented at 0:16 am on May 21, 2020:

This doesn’t seem like a subset of std::any’s functionality – as far as I can tell std::any makes a copy of an object, and can’t be used for the behaviour Ref offers (providing a reference to an arbitrary object). Just a comment nit: implementing copy semantics seems like a waste of time, and moving to std::any later seems sensible – it just won’t be a drop-in change, as far as I can see.

ryanofsky commented at 3:25 am on May 21, 2020:

Thanks for the review. std::any can hold pointers and reference wrappers, so there is no problem here. I’m going to mark the style comments resolved because I disagree with them and don’t want to create extended off-topic conversations. But if there’s anything that should be reconsidered, definitely do follow up. Review suggestions tend to be most useful when they are specific and say something about the motivation behind the suggestion. That way, if there’s disagreement about the suggestion, something else can be done to address whatever the motivation for it was.

in src/httprpc.cpp:297 in 6fca33b2ed outdated

294     LogPrint(BCLog::RPC, "Starting HTTP RPC server\n");
295     if (!InitRPCAuthentication())
296         return false;
297 
298-    RegisterHTTPHandler("/", true, HTTPReq_JSONRPC);
299+    auto handle_rpc = [&context](HTTPRequest* req, const std::string&) { return HTTPReq_JSONRPC(context, req); };

ajtowns commented at 0:27 am on May 21, 2020:

Should just add context as a param to RegisterHTTPHandler(), and change the definitions of HTTPRequestHandler and HTTPPathHandler to accept/track the context, rather than have lots of lambdas? Something like https://github.com/ajtowns/bitcoin/commits/202005-pr18740-tweaks

in src/rpc/misc.cpp:403 in 6fca33b2ed outdated

398@@ -398,9 +399,10 @@ static UniValue mockscheduler(const JSONRPCRequest& request)
399     }
400 
401     // protect against null pointer dereference
402-    CHECK_NONFATAL(g_rpc_node);
403-    CHECK_NONFATAL(g_rpc_node->scheduler);
404-    g_rpc_node->scheduler->MockForward(std::chrono::seconds(delta_seconds));
405+    CHECK_NONFATAL(request.context.Has<NodeContext>());
406+    NodeContext& node = request.context.Get<NodeContext>();

ajtowns commented at 1:43 am on May 21, 2020:

EnsureNodeContext ?

MarcoFalke commented at 10:50 am on May 21, 2020:

I think russ tries to keep the previous structure of the code, but I agree this can be changed in a follow-up

in src/rpc/request.h:43 in 6fca33b2ed outdated

37@@ -34,8 +38,9 @@ class JSONRPCRequest
38     std::string URI;
39     std::string authUser;
40     std::string peerAddr;
41+    const util::Ref& context;
42 
43-    JSONRPCRequest() : id(NullUniValue), params(NullUniValue), fHelp(false) {}
44+    JSONRPCRequest(const util::Ref& context) : id(NullUniValue), params(NullUniValue), fHelp(false), context(context) {}

ajtowns commented at 2:32 am on May 21, 2020:

Ref& _context and context(_context)? We usually use different names for arguments and members, don’t we?

MarcoFalke commented at 10:49 am on May 21, 2020:

This will cause -Wshadow warnings, but luckily we don’t have them enabled anymore

MarcoFalke commented at 10:53 am on May 21, 2020:

This can be fixed up in the follow-up that switches to C++17

ajtowns commented at 2:39 am on May 21, 2020: member

ACK b3f7f375efb9a9ca9a7a4f2caf41fe3df2262520

MarcoFalke commented at 10:52 am on May 21, 2020: member

re-ACK b3f7f375ef, only change is adding back const and more tests 🚾

Signature:

 0-----BEGIN PGP SIGNED MESSAGE-----
 1Hash: SHA512
 2
 3re-ACK b3f7f375ef, only change is adding back const and more tests 🚾
 4-----BEGIN PGP SIGNATURE-----
 5
 6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
 7pUjEBAv/RaWaCyOsjaMttBcKiwYoYmFFtu0dDqcwQ8icmd/JotFyemomPv1LSpOs
 8+rmy/8gpfyM875zlzSJ/jg0ELlQm7LS7RQecVSSYCx27J8U6olXBJILuPx4T8yJs
 9DY3DABlfI1lQv7rffyZu0mxRYv8b4sGh+80ZTL4t3WOuvsdnS+PsqiK+BJiG571k
109Oeg4BQxLaYKR5Q80n74ATb4tv2eogpYJ8JmKRIOZ3DWOtFsSot2WCEmaxOJc0If
11RJqEGeJ/sL8+hM3lEZm4HYI/eV0/WpezgnpX8pn7kvcpnS4NcElPSzXiFYpYjKYe
12T4dSFvRg5rZaqJ61PCHBjFk5mMV0sHtRQ4mbGiAiCPvhpoVGbbEq+3YY2q5+ZXs0
13E2PvUzHz6wqiK7ZmtpmM3CiuA8cu3MgujgGJF5ou5ZW1HIGjne3brc2lKnl7SfNO
14m5TghZ/FY8JiBnk/Wwzp7WSf3Zf9Q7SD6sqTy9/PKQEquWSNQNxsc/hziYfSpjYF
15Z1obJ5Pr
16=nEIH
17-----END PGP SIGNATURE-----

Timestamp of file with hash 4de1c5a739df99abe18f469939c72f67f85aab41eb67e464e5ba55c4a6d9c8a4 -

MarcoFalke merged this on May 21, 2020

MarcoFalke closed this on May 21, 2020

sidhujag referenced this in commit a1f0893177 on May 21, 2020

domob1812 referenced this in commit 1cd26b1e6d on May 25, 2020

domob1812 referenced this in commit dec43d536c on May 25, 2020

ryanofsky referenced this in commit 2058621ed3 on May 28, 2020

ryanofsky referenced this in commit e1cfcd4cf8 on May 29, 2020

ryanofsky referenced this in commit 272498311d on May 29, 2020

ryanofsky referenced this in commit 4a7253ab6c on Jun 1, 2020

MarcoFalke referenced this in commit 0fc6ea216c on Jun 5, 2020

sidhujag referenced this in commit a7b3468226 on Jun 5, 2020

deadalnix referenced this in commit 07f35b9861 on Oct 20, 2020

jasonbcox referenced this in commit 5c70631e07 on Oct 20, 2020

jasonbcox referenced this in commit b37ed6f1ed on Oct 20, 2020

deadalnix referenced this in commit 2c58f52e8e on Oct 20, 2020

janus referenced this in commit f20934f4ea on Nov 15, 2020

hebasto commented at 0:34 am on March 28, 2021: member

@ryanofsky

This uses a hybrid of the approaches suggested in #17548. Instead of using std::any, which isn’t available in c++11, or void*, which isn’t type safe, it uses a small new util::Ref helper class, which acts like a simplified std::any that only holds references, not values.

The std::any requires that a type of a contained object must be CopyConstructible. But std::is_copy_constructible<NodeContext>::value == false.

So, even with C++17, there are no simple ways to drop util::Ref in favor of std::any, unfortunately.

Or did I miss something?

fanquake commented at 0:36 am on March 28, 2021: member

So, even with C++17, there are no simple ways to drop util::Ref in favor of std::any, unfortunately.

It’s being dropped for std::any in #21366.

PastaPastaPasta referenced this in commit 9f2d812b7d on Jun 27, 2021

PastaPastaPasta referenced this in commit 43eeca6d47 on Jun 28, 2021

PastaPastaPasta referenced this in commit 278ec083a7 on Jun 29, 2021

PastaPastaPasta referenced this in commit e9e3cadc79 on Jul 1, 2021

PastaPastaPasta referenced this in commit 22a576b4bd on Jul 1, 2021

PastaPastaPasta referenced this in commit d54f195f3d on Jul 14, 2021

kittywhiskers referenced this in commit 674eee8dc7 on Apr 23, 2022

kittywhiskers referenced this in commit 0ab4520ae7 on Apr 24, 2022

kittywhiskers referenced this in commit b9c650a14b on May 3, 2022

kittywhiskers referenced this in commit 431d159281 on May 5, 2022

kittywhiskers referenced this in commit b7816a8baa on May 6, 2022

kittywhiskers referenced this in commit 0c4a23e6fd on May 7, 2022

kittywhiskers referenced this in commit e2f6ce4f39 on May 11, 2022

kittywhiskers referenced this in commit fbcb7559a6 on May 13, 2022

kittywhiskers referenced this in commit 472369205f on May 17, 2022

kittywhiskers referenced this in commit 1a65972c2e on May 18, 2022

PastaPastaPasta referenced this in commit 22a24ab5b7 on May 19, 2022

malbit referenced this in commit 72b925f69a on Aug 7, 2022

DrahtBot locked this on Aug 16, 2022

Remove g_rpc_node global #18740

Conflicts