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

rpcclient: Add getchaintxstats JSON-RPC client command #1571

Merged
merged 1 commit into from
Jun 15, 2020

Conversation

lindlof
Copy link
Contributor

@lindlof lindlof commented May 11, 2020

Add JSON-RPC client command

@lindlof lindlof changed the title Add getchaintxstats JSON-RPC client command rpcclient: Add getchaintxstats JSON-RPC client command May 16, 2020
@jakesylvestre
Copy link
Collaborator

@lindlof would you mind rebasing this? One consequence of #1575 is some of these PR's need to be rebased to exclude the .travis.yml and include the .github/workflows

@lindlof
Copy link
Contributor Author

lindlof commented May 23, 2020

@jakesyl Roger! Rebased and includes .github/workflows now

rpcclient/chain.go Outdated Show resolved Hide resolved
Copy link
Collaborator

@Rjected Rjected left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, good addition! I'd just like the btcjson and rpcclient methods to be consistent with their packages.

Comment on lines 366 to 373
// Int32OrNil defines a type for representing nullable numeric JSON-RPC parameters.
// This is a way to explicitly marshall a null param as they are dropped by default.
//
// Useful when default value is unknown client-side and null param
// needs to be included to define following params.
type Int32OrNil struct {
Value *int32
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the rest of the package does not introduce types like these, I don't see how it becomes necessary here. I would opt to stay consistent with the package and handle optional parameters without defining a new type. In btcjson the ...Cmd types use pointers to represent optional parameters, so in this case a *int32 will do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed it's a bit bloaty and it's not obvious why it was needed. The reason for Int32OrNil is to allow providing the JSON null value from command line in the following format:

btcctl getchaintxstats null 0000000000000000000039128c26efb79f720e54e4f741171c41b05debde0cdf

It allows user to provide blockhash while also providing nblocks as null. Possible options using *int32:

  • Define a default nblocks
    • nblocks should be calculated server side with server's chain parameters
    • Reasonable default could be 4320 which is the server default in mainnet Bitcoin Core
  • Allow providing null for *int32 in command parsing
    • getchaintxstats seems to be an exception so I avoided large changes to command parsing
  • Forcing command line users to define nblocks to be able to define blockhash
  • Asking user to provide e.g. 0 for null value

These are the options that I found. What do you suggest?

Copy link
Collaborator

@Rjected Rjected Jun 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm yeah I see the challenge here. I think the larger issue is that we don't support null for *int32 parameters, and given there are a bunch of RPC commands which have optional integer parameters, we should try to support this at some point. For now, let's stick with a *int32, and we can have a default jsonrpcdefault:"4320".

In the meantime, I'll put up an issue for this, since right now we basically just use defaults which are not null, and also don't allow providing null for *int32 in command parsing. If we eventually do have these features, we can then do a bit of a btcjson cleanup and new command implementations will be a lot more straightforward. Sound good?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using *int32 instead of Int32OrNil now. Adding the jsonrpcdefault didn't actually help with either command line nor rpcclient usage. The 4320 is not the real default so I didn't add any jsonrpcdefault. nblocks must now be defined to define blockhash in the JSON-RPC request.

// the returned instance.
//
// See GetChainTxStats for the blocking version and more details.
func (c *Client) GetChainTxStatsAsync(nBlocks *int32, blockHash *chainhash.Hash) FutureGetChainTxStatsResult {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unlike btcjson, the rpcclient package consistently exposes multiple method signatures to allow the user to pass optional parameters. I would suggest following that pattern for consistency reasons as well.
In this case GetChainTxStats would have no arguments, and you would implement GetChainTxStatsBlockHash, GetChainTxStatsNBlocks, GetChainTxStatsBlockHashNBlocks. There has been a similar discussion in #1589 about the design of the rpcclient package.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rpcclient functions GetChainTxStats, GetChainTxStatsNBlocks and GetChainTxStatsNBlocksBlockHash are now provided for consistency

@@ -475,7 +475,9 @@ func assignField(paramNum int, fieldName string, dest reflect.Value, src reflect
paramNum, fieldName, destBaseType)
return makeError(ErrInvalidType, str)
}
dest.Set(reflect.ValueOf(concreteVal).Elem())
if concreteVal != nil {
dest.Set(reflect.ValueOf(concreteVal).Elem())
Copy link
Collaborator

@Rjected Rjected Jun 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is a case where we would panic, we should test it as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed this command parsing change because it was part of now removed Int32OrNil. This issue no longer relevant to this PR.

Copy link
Collaborator

@Rjected Rjected left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sweet, LGTM

Copy link
Member

@jcvernaleo jcvernaleo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

@jcvernaleo jcvernaleo merged commit 73d69f0 into btcsuite:master Jun 15, 2020
@onyb onyb mentioned this pull request Jul 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants