Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add paytxfee and errors JSON fields where appropriate #6257

Merged
merged 1 commit into from Jun 15, 2015

Conversation

scmorse
Copy link

@scmorse scmorse commented Jun 8, 2015

Added fields that were missing from a few of the basic info rpc requests.

getwalletinfo

  • paytxfee

getnetworkinfo

  • warnings

@jonasschnelli
Copy link
Contributor

utACK for the paytxfee in getwalletinfo.

Tend to NACK the errors extending. The errors are mostly warnings and i think it won't make sense to add them to serval rpc commands.
I think a good example of how the errors field could get handled is the signrawtransaction rpc call.
The getinfo rpc call is not e good example IMO.

@laanwj
Copy link
Member

laanwj commented Jun 9, 2015

@jonasschnelli I agree that errors shouldn't be added to multiple RPC calls. It does belong on one other RPC call though as otherwise it would disappear when the deprecated getinfo is removed.
(same for version, and protocolversion)

Edit: protocolversion is already on getnetworkinfo, I forgot.

@jonasschnelli
Copy link
Contributor

It just came to my mind that there is also the possibility of adding general information "one level above JSON" and that would mean add a custom HTTP response header (X-Bitcoin-Version, etc.). But not sure if this is a good idea.

@laanwj
Copy link
Member

laanwj commented Jun 9, 2015

@jonasschnelli Sounds like a good idea, but it may be harder to get at in some client implementations. It doesn't exclude including the version on some RPC call.

@scmorse
Copy link
Author

scmorse commented Jun 9, 2015

@jonasschnelli which one RPC call do you think the errors flag from getinfo should be included in, then? Maybe errors isn't the best name, could be alert or alerts?

@jonasschnelli
Copy link
Contributor

@scmorse: at the moment, the general error states (actually mostly warnings) can be loaded over the getinfo() call (which is okay IMO). It should be named "warnings", but changing this would break the API (which should be avoided).

My recommendation would be to just add the paytxfee field as you did and remove all the "error" changes. Or do you see a benefit in having the error object in getblockchaininfo and getnetworkinfo?

@laanwj
Copy link
Member

laanwj commented Jun 10, 2015

Let's put it in getnetworkinfo. Nearly all the alerts come from the network or at least signal network conditions.

@scmorse
Copy link
Author

scmorse commented Jun 11, 2015

@laanwj @jonasschnelli Updated getnetworkinfo to have a "warnings" field and getwalletinfo to include the "paytxfee".

@jonasschnelli
Copy link
Contributor

utACK.

Something for another PR would be to rename the "statusbar" warnings category to just "status" or something to avoid that one could think this is for UI only. But really really a minor low prio thing.

@laanwj
Copy link
Member

laanwj commented Jun 12, 2015

utACK.

I'd say don't bother renaming the category in this pull. I agree it's named wrongly and it's weird to pass in a string there anyway (should be an enum). Also the other category "rpc" is never used except to detect "safe mode" in OnRPCPreCommand by checking if the string is empty, which is also quite strange. It's very weird code so renaming the category wouldn't do it justice :)

@laanwj laanwj merged commit ef2a3de into bitcoin:master Jun 15, 2015
laanwj added a commit that referenced this pull request Jun 15, 2015
ef2a3de Add paytxfee to getwalletinfo, warnings to getnetworkinfo (Stephen)
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants