rpc: Document default values for optional arguments#14877
rpc: Document default values for optional arguments#14877maflcko merged 1 commit intobitcoin:masterfrom
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
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. |
eeee62f to
fadea91
Compare
|
Thanks @practicalswift. Fixed my language |
fadea91 to
fa0c24c
Compare
| { | ||
| {"conf_target", RPCArg::Type::NUM, /* opt */ false, /* default_val */ "", "Confirmation target in blocks (1 - 1008)"}, | ||
| {"threshold", RPCArg::Type::NUM, /* opt */ true, /* default_val */ "", "The proportion of transactions in a given feerate range that must have been\n" | ||
| {"threshold", RPCArg::Type::NUM, /* opt */ true, /* default_val */ "0.95", "The proportion of transactions in a given feerate range that must have been\n" |
There was a problem hiding this comment.
what about using a stringprint of the threshold variable?
|
utACK fa0c24c |
|
ACK fa0c24c |
ryanofsky
left a comment
There was a problem hiding this comment.
ACK fa0c24c. I checked help output using the hack from #14726 (review)
This is a nice documentation change. If you wanted to follow up with more improvements I have some suggestions below:
- The fallback descriptions like "
fallback to wallet's default" are vague and could be described in more detail. - I don't think saying
(default=null)or(default=omitted)is ever helpful. Just because of the way we check arguments, omitting an argument is always equivalent to passingnull. And(default=omitted)is just a tautology. The point of the default documentation should be to say what an RPC call will do when an argument isnullor omitted. I actually think it would be better to drop the all the(default=null)and(default=omitted)strings if they can't be replaced with something more constructive, to avoid creating a bad precedent for future changes.
| {"bantime", RPCArg::Type::NUM, /* opt */ true, /* default_val */ "", "time in seconds how long (or until when if [absolute] is set) the IP is banned (0 or empty means using the default time of 24h which can also be overwritten by the -bantime startup argument)"}, | ||
| {"absolute", RPCArg::Type::BOOL, /* opt */ true, /* default_val */ "", "If set, the bantime must be an absolute timestamp in seconds since epoch (Jan 1 1970 GMT)"}, | ||
| {"bantime", RPCArg::Type::NUM, /* opt */ true, /* default_val */ "0", "time in seconds how long (or until when if [absolute] is set) the IP is banned (0 or empty means using the default time of 24h which can also be overwritten by the -bantime startup argument)"}, | ||
| {"absolute", RPCArg::Type::BOOL, /* opt */ true, /* default_val */ "false", "If set, the bantime must be an absolute timestamp in seconds since epoch (Jan 1 1970 GMT)"}, |
There was a problem hiding this comment.
/If set/If true/ might be more accurate
If there is "default=" string outputted for each optional argument, functional test could be made that checks that people don't forget to document optional argument defaults for a new RPCs. |
IMO, better to write that test with a list of exceptions for grandfathered, undocumented default arguments, than to leave bad documentation scattered over the codebase, especially since existing documentation is often used as a template for new documentation |
|
Oh, yes, short list of a few exceptions probably is better idea. |
|
I have changes piled up locally to enforce that it is either a required arg or a default value is provided at compile time. |
fa0c24c rpc: Document default values for optional arguments (MarcoFalke) Pull request description: Tree-SHA512: e1f5ea67d7ac67526ae87bffaeb308a9ad68632e161fe0148cd431a340bb7a30def18f1dbc7e98c6c1c269ac8942fd5d5334c85c48e4fb1cead70a42536b6eef
|
@MarcoFalke what do you want to do with all the |
|
@ryanofsky Your suggestion is a one-line change after #14918, so either you leave feedback there or create a pull request after #14918 is merged. |
fa5e6ef wallet: Fixup rescanblockchain result doc (MarcoFalke) Pull request description: This was probably accidentally added to the wrong line when addressing the feedback here: #7061 (comment) I already added the default values in #14877, but it could be clarified more that this really has no specific block height as default value, since the tip can change during a rescan. Tree-SHA512: 48a3c5143e2b7129ee8f396d2e77550cb393fbe45f5936aeebeb7a201d61560336a3ae47b26bb757a4dbbe217e06abfd67a5a673aef266b6c4d7a80d049a2b49
Summary: This is a backport of Core [[bitcoin/bitcoin#14877 | PR14877]] Test Plan: ninja all check-all Reviewers: #bitcoin_abc, Fabien Reviewed By: #bitcoin_abc, Fabien Subscribers: Fabien Differential Revision: https://reviews.bitcoinabc.org/D6218
fa5e6ef wallet: Fixup rescanblockchain result doc (MarcoFalke) Pull request description: This was probably accidentally added to the wrong line when addressing the feedback here: bitcoin#7061 (comment) I already added the default values in bitcoin#14877, but it could be clarified more that this really has no specific block height as default value, since the tip can change during a rescan. Tree-SHA512: 48a3c5143e2b7129ee8f396d2e77550cb393fbe45f5936aeebeb7a201d61560336a3ae47b26bb757a4dbbe217e06abfd67a5a673aef266b6c4d7a80d049a2b49
fa5e6ef wallet: Fixup rescanblockchain result doc (MarcoFalke) Pull request description: This was probably accidentally added to the wrong line when addressing the feedback here: bitcoin#7061 (comment) I already added the default values in bitcoin#14877, but it could be clarified more that this really has no specific block height as default value, since the tip can change during a rescan. Tree-SHA512: 48a3c5143e2b7129ee8f396d2e77550cb393fbe45f5936aeebeb7a201d61560336a3ae47b26bb757a4dbbe217e06abfd67a5a673aef266b6c4d7a80d049a2b49
No description provided.