Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843)#10871
Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843)#10871laanwj merged 2 commits intobitcoin:masterfrom
Conversation
|
Concept ACK. |
A simple tool-test like -tx's wont work here as it requires a running bitcoind. |
|
rebased |
|
bad rebase: #10798 is now rebased and ready for merge. It should be fairly straightforward to rebase this on top of that to add a functional test. |
|
Test here if you want it: https://github.com/jnewbery/bitcoin/tree/pr10871_test Builds on top of #10798. Test currently fails because the output for |
|
I think the docs should at least mention something about atomicity. Every other API to Bitcoin Core is atomic, so it feels very strange to add a new one which is not. |
I know you don't like this particular changej, but this is reaching FUD levels here, what exactly are you concerned about happening here? Within a group, the values are as atomic as ever. Some of these don't change at runtime at all, some hardly change. Can you indicate exactly between which two you're afraid non-atomicity is going to give a problem, in practice? If not, let's please leave this behind us. |
|
My only real atomicity concern is between blocks and balance - ie that you may call getinfo, see a balance and assume that it is current as of a given block height. It may be of lesser concern in just bitcoin-cli, as its not intended to be used in scripts, hence my note that I'd be ok with just documenting this behavior, though I could still see someone fucking it up in some way. |
Yes, that's a valid concern. Also outside this PR - there is currently no way to query up to which height the wallet has processed. Especially when the wallet and node are decoupled further w/ threads or even processes. We should add a |
I believe that There's been discussion of adding the wallet's best block to |
|
Is this still being actively worked on? Next steps would be:
|
|
I am still working on this, just got sidetracked with other stuff. |
e697d54 to
c432fc4
Compare
|
Took the test and rebased.
What discrepancies? |
See above:
Once #10838 is merged, then that's no longer an issue. After #10838, I think the way to test this would be to collect the responses from |
I think that we should be doing that instead of comparing against |
c432fc4 to
5d2341c
Compare
|
I modified the test to compare against the |
jnewbery
left a comment
There was a problem hiding this comment.
one nit inline.
Please tidy up commits. First two commits should be squashed, and final two commits should be squashed into a second commit.
src/rpc/protocol.cpp
Outdated
There was a problem hiding this comment.
please also add braces to these if blocks
5d2341c to
d1e4ea8
Compare
|
Tidied up commits |
d1e4ea8 to
226fa64
Compare
src/bitcoin-cli.cpp
Outdated
There was a problem hiding this comment.
You've lost the static keyword for this function in your rebase.
226fa64 to
af61f69
Compare
jnewbery
left a comment
There was a problem hiding this comment.
Some comments in line.
You seem to have lost the test in your commit squashing.
src/bitcoin-cli.cpp
Outdated
There was a problem hiding this comment.
I think it would be clearer to not reset args here. The only reason you're doing this is to pass the if (args.size() < 1) check below and then extract strMethod.
Instead, just move the if (args.size() < 1) check into the else branch. GetinfoRequestHandler.PrepareRequest() doesn't require strMethod or args.
Taking this further, you could add a method to DefaultRequestHandler to update the strMethod and args, and then update the PrepareRequest() method to not take any arguments.
src/bitcoin-cli.cpp
Outdated
src/bitcoin-cli.cpp
Outdated
There was a problem hiding this comment.
nit: function arguments should not be hungarian/camel case strMethod -> method
There was a problem hiding this comment.
nit: function arguments should not be hungarian/camel case strMethod -> method
not currently addressed
af61f69 to
47458fe
Compare
f2fde56 to
2cf0866
Compare
|
Fixed the test failure. |
jnewbery
left a comment
There was a problem hiding this comment.
Looks really good. Just a few nitty comments inline
src/bitcoin-cli.cpp
Outdated
src/bitcoin-cli.cpp
Outdated
There was a problem hiding this comment.
nit: function arguments should not be hungarian/camel case strMethod -> method
not currently addressed
test/functional/bitcoin_cli.py
Outdated
There was a problem hiding this comment.
We know that the wallet isn't locked, so this won't be tested. I don't think there's any benefit in adding a test code that won't be executed (in fact it's slightly deleterious since a casual reader might think that we're actually testing this).
Either:
- lock the wallet and actually test this
- add a comment saying we're not testing the field because the wallet isn't locked.
I think either is fine.
2cf0866 to
5ca97e5
Compare
|
Addressed nits (sorry for the delay). |
|
Tested ACK 5ca97e5f03d7352558991e8eb26bb58dc4eec453. Thanks for sticking with this! |
src/bitcoin-cli.cpp
Outdated
There was a problem hiding this comment.
Are you going to update the help text to note something about balance/height atomicity? The old getinfo takes cs_main and cs_wallet and returns atomic information, this no longer does. getwalletinfo will likely eventually return something so that you can report if a result was atomic here (probably a follow-up to #10286).
There was a problem hiding this comment.
What do you suggest that the text for such a note be?
There was a problem hiding this comment.
as getinfo is misleading here too, see #10871 (comment), I still don't see this as a strong point, but as it seems to bother @TheBlueMatt very much let's just add it...
|
Something like "Note that unlike server-side RPC calls, the results of getinfo is the result of multiple non-atomic requests. Some entries in the result may represent results from different states (eg wallet balance may be as of a different block from the chain state reported)"
…On September 27, 2017 8:06:29 PM EDT, Andrew Chow ***@***.***> wrote:
achow101 commented on this pull request.
> @@ -37,6 +37,7 @@ std::string HelpMessageCli()
strUsage += HelpMessageOpt("-?", _("This help message"));
strUsage += HelpMessageOpt("-conf=<file>", strprintf(_("Specify
configuration file (default: %s)"), BITCOIN_CONF_FILENAME));
strUsage += HelpMessageOpt("-datadir=<dir>", _("Specify data
directory"));
+ strUsage += HelpMessageOpt("-getinfo", _("Get general information
from the remote server"));
What do you suggest that the text for such a note be?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#10871 (comment)
|
This adds the infrastructure `BaseRequestHandler` class that takes care of converting bitcoin-cli arguments into a JSON-RPC request object, and converting the reply into a JSON object that can be shown as result. This is subsequently used to handle the `-getinfo` option, which sends a JSON-RPC batch request to the RPC server with `["getnetworkinfo", "getblockchaininfo", "getwalletinfo"]`, and after reply combines the result into what looks like a `getinfo` result. There have been some requests for a client-side `getinfo` and this is my PoC of how to do it. If this is considered a good idea some of the logic could be moved up to rpcclient.cpp and used in the GUI console as well. Extra-Author: Andrew Chow <[email protected]>
Extra-Author: Andrew Chow <[email protected]>
5ca97e5 to
5e69a43
Compare
|
Added the atomicity note to the help text. |
|
utACK 5e69a43 |
…8843) 5e69a43 Add test for bitcoin-cli -getinfo (John Newbery) 3826253 rpc: Handle `getinfo` locally in bitcoin-cli w/ `-getinfo` (Wladimir J. van der Laan) Pull request description: Since @laanwj doesn't want to maintain these changes anymore, I will. This PR is a revival of #8843. I have addressed @jnewbery's comments. Regarding atomicity, I don't think that is a concern here. This is explicitly a new API and those who use it will know that this is different and that it is not atomic. Tree-SHA512: 9664ed13a5557bda8c43f34d6527669a641f260b7830e592409b28c845258fc7e0fdd85dd42bfa88c103fea3ecdfede5f81e3d91870e2accba81c6d6de6b21ff
|
Thanks, helped.
…On Thu, Sep 28, 2017 at 2:54 AM, Andrew Chow ***@***.***> wrote:
Added the atomicity note to the help text.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10871 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AdBhR6LWhfiCahFF4ZmMTHD0vw0tUAmcks5smvxWgaJpZM4Ob_vu>
.
|
This adds the infrastructure `BaseRequestHandler` class that takes care of converting bitcoin-cli arguments into a JSON-RPC request object, and converting the reply into a JSON object that can be shown as result. This is subsequently used to handle the `-getinfo` option, which sends a JSON-RPC batch request to the RPC server with `["getnetworkinfo", "getblockchaininfo", "getwalletinfo"]`, and after reply combines the result into what looks like a `getinfo` result. There have been some requests for a client-side `getinfo` and this is my PoC of how to do it. If this is considered a good idea some of the logic could be moved up to rpcclient.cpp and used in the GUI console as well. Extra-Author: Andrew Chow <[email protected]> Github-Pull: bitcoin#10871 Rebased-From: 3826253
|
can someone please tell me how to apply this so that getinfo can work with the yiimp opensource pool files? |
|
@crombiecrunch Please submit a pull request upstream, replacing getinfo['balance'] with getwalletinfo['balance'] in the open source code. |
Summary: This adds the infrastructure `BaseRequestHandler` class that takes care of converting bitcoin-cli arguments into a JSON-RPC request object, and converting the reply into a JSON object that can be shown as result. This is subsequently used to handle the `-getinfo` option, which sends a JSON-RPC batch request to the RPC server with `["getnetworkinfo", "getblockchaininfo", "getwalletinfo"]`, and after reply combines the result into what looks like a `getinfo` result. There have been some requests for a client-side `getinfo` and this is my PoC of how to do it. If this is considered a good idea some of the logic could be moved up to rpcclient.cpp and used in the GUI console as well. Extra-Author: Andrew Chow <[email protected]> Add test for bitcoin-cli -getinfo Extra-Author: Andrew Chow <[email protected]> Backport of PR10871 bitcoin/bitcoin#10871 Completes T586 Test Plan: make check test_runner.py bitcoin-cli -getinfo Reviewers: jasonbcox, deadalnix, Fabien, O1 Bitcoin ABC, #bitcoin_abc Reviewed By: deadalnix, O1 Bitcoin ABC, #bitcoin_abc Differential Revision: https://reviews.bitcoinabc.org/D2787
Summary: This adds the infrastructure `BaseRequestHandler` class that takes care of converting bitcoin-cli arguments into a JSON-RPC request object, and converting the reply into a JSON object that can be shown as result. This is subsequently used to handle the `-getinfo` option, which sends a JSON-RPC batch request to the RPC server with `["getnetworkinfo", "getblockchaininfo", "getwalletinfo"]`, and after reply combines the result into what looks like a `getinfo` result. There have been some requests for a client-side `getinfo` and this is my PoC of how to do it. If this is considered a good idea some of the logic could be moved up to rpcclient.cpp and used in the GUI console as well. Extra-Author: Andrew Chow <[email protected]> Add test for bitcoin-cli -getinfo Extra-Author: Andrew Chow <[email protected]> Backport of PR10871 bitcoin/bitcoin#10871 Completes T586 Test Plan: make check test_runner.py bitcoin-cli -getinfo Reviewers: jasonbcox, deadalnix, Fabien, O1 Bitcoin ABC, #bitcoin_abc Reviewed By: deadalnix, O1 Bitcoin ABC, #bitcoin_abc Differential Revision: https://reviews.bitcoinabc.org/D2787
…al of bitcoin#8843) 5e69a43 Add test for bitcoin-cli -getinfo (John Newbery) 3826253 rpc: Handle `getinfo` locally in bitcoin-cli w/ `-getinfo` (Wladimir J. van der Laan) Pull request description: Since @laanwj doesn't want to maintain these changes anymore, I will. This PR is a revival of bitcoin#8843. I have addressed @jnewbery's comments. Regarding atomicity, I don't think that is a concern here. This is explicitly a new API and those who use it will know that this is different and that it is not atomic. Tree-SHA512: 9664ed13a5557bda8c43f34d6527669a641f260b7830e592409b28c845258fc7e0fdd85dd42bfa88c103fea3ecdfede5f81e3d91870e2accba81c6d6de6b21ff
Since @laanwj doesn't want to maintain these changes anymore, I will.
This PR is a revival of #8843. I have addressed @jnewbery's comments.
Regarding atomicity, I don't think that is a concern here. This is explicitly a new API and those who use it will know that this is different and that it is not atomic.