-
Notifications
You must be signed in to change notification settings - Fork 84
[FIX] [RPC] floresta-cli command gettransaction mismatch with florestad rpc server
#616
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
base: master
Are you sure you want to change the base?
Conversation
|
You can see the And validate that |
|
You should actually rename to |
Reading the Bitcoin RPC documentation, i found some mismatch with this implementations.
References: |
Yeah, I think it should be easy to implement |
jaoleal
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for delivering some work on this. Ive written some suggestions, care to take a look ?
doc/rpc/getrawtransaction.md
Outdated
|
|
||
| * `txid` - (string, required) The transaction id | ||
|
|
||
| * `verbose` - (boolean, optional) If false, return a string, otherwise return a json object |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| * `verbose` - (boolean, optional) If false, return a string, otherwise return a json object | |
| * `verbose` - (flag, optional) When set, returns more human-readable and detailed data from the specified transaction, otherwise it will just return the hex encoded transaction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not a flag, it is a argument, defined in:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh... since we have only one level of verbosity can you make it a flag ?
The changes are always oriented as defined on the bitcoin core docs and is correct to use an Option but actually one of a u8 to theoretically cover its API, but i dont see an advantage in doing that so i think its better to correctly make it a flag, WYT ?
Having an Option of a Boolean doesnt make any sense XD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We use Option because we have a state when verbose is not defined, we will use as false statement. In other words, when verbose is set as None will be define as false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, please allow me to refrain better... The utility of an Option and a Boolean is similar when they represent two states, correct ? These two states that tell us what to do in such a case... when you have a boolean inside a Option<> you have a total of 3 states.
None
Some(true), and
Some(false)
but this is not necessary because you only need two states to make this verbose feature to work, that being a boolean alone representing whether the verbose is enabled right ?
The final result that i thought is a more concise and intuitive API delegating the presence check to the Clap crate because he alone can already tell which value to return in the case of the absence of an argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can apply this boolean statement into floresta-cli client, but this params need to be Option inside florestad rpc server, because other clients (like Bitcoin-cli) use this param as optional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, if youre trying to be strictly compliant to Bitcoin Core API the objective here is totally different.
in order to make it totally compatible you can follow something similar as i have done with the getblock command in this PR (the link will point to you the correct line)
so instead of having an Option<Bool> the change here needs to support an Option<u8>.
heres the documentation of the bitcoin core rpc at the latest version that im using to guide mine contributions to the #453
Also, to stick with the API design goal, care to change the inner method name ? get_transaction needs to be get_raw_transaction
| @@ -43,7 +43,7 @@ pub trait FlorestaRPC { | |||
| /// This method returns a transaction that's cached in our wallet. If the verbosity flag is | |||
| /// set to false, the transaction is returned as a hexadecimal string. If the verbosity | |||
| /// flag is set to true, the transaction is returned as a json object. | |||
| fn get_transaction(&self, tx_id: Txid, verbosity: Option<bool>) -> Result<Value>; | |||
| fn get_raw_transaction(&self, tx_id: Txid, verbosity: Option<bool>) -> Result<Value>; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here the docs needs to be changed to include the "getrawtransaction.md" one.
| #[command(name = "gettransaction")] | ||
| GetTransaction { txid: Txid, verbose: Option<bool> }, | ||
| #[command(name = "getrawtransaction")] | ||
| GetRawTransaction { txid: Txid, verbose: Option<bool> }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| GetRawTransaction { txid: Txid, verbose: Option<bool> }, | |
| GetTransaction { | |
| txid: Txid, | |
| #[arg( | |
| short = 'v', | |
| long = "verbose", | |
| required = false, | |
| default_value_t = false | |
| )] | |
| verbose: bool, | |
| }, |
|
Hi, @TheMhv some of the requested changes was marked as resolved but they werent addressed... Can you please take a look at these below ? #616 (comment) Please tell me if you need help addressing them or if you cant for some other reason. |
|
Needs rebase |
|
Hi @TheMhv , do you intend to continue working on this PR? |
I'm little confused about the changes, I've need to review. Maybe you can help me to finish this PR |
This RPC must be Bitcoin Core compliant. The verbosity parameter should be numeric, not boolean. Documentation needs to follow the project's template structure. RPC Reference: https://bitcoincore.org/en/doc/29.0.0/rpc/rawtransactions/getrawtransaction/ |
d5ad73d to
3a97f8f
Compare
What is the purpose of this pull request?
Which crates are being modified?
Description and Notes
#453
The command
gettransactionis already implemented but is mismatch with command used insideflorestadrpc server.florestadexpectsgetrawtransactionwhilefloresta-clisendsgettransactioncommand.I changed the command
getrawtransactiontogettransactionthat's a correct functionality insideflorestadrpc server.How to verify the changes you have done?
gettransactioncommand work correctly usingfloresta-cli.Contributor Checklist
just pcc(recommended but slower)just lint-features '-- -D warnings' && cargo test --releaseFinally, you are encouraged to sign all your commits (it proves authorship and guards against tampering—see How (and why) to sign Git commits and GitHub's guide to signing commits).