-
Notifications
You must be signed in to change notification settings - Fork 68
Add get_address_stats and get_address_txns endpoints
#104
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 get_address_stats and get_address_txns endpoints
#104
Conversation
Pull Request Test Coverage Report for Build 11334093933Details
💛 - Coveralls |
|
@oleonardolima addressed the comments, naming is hard I went with |
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.
It's looking good! I think it all can be squashed into a single commit, e.g.: feat(api): add `/address/:address` and `/address/:address/txs` endpoints
| pub mempool_stats: AddressTxnSummary, | ||
| } | ||
|
|
||
| #[derive(Debug, Copy, Clone, PartialEq, Eq, Deserialize)] |
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.
What do we need the Copy one for?
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.
I like to derive Copy whenever possible especially for libraries, because we don't know how the end user is going to use it. It would be nicer for them to be able to Copy and dereference it instead of cloning it.
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.
I don't see much problem, however, we are not deriving it for other APIs, so would rather keep that standard.
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.
Can we merge this in and I can go through the API and add Copy to the other structs that make sense? @oleonardolima ?
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.
I'm fine with it, I'd like to see what others think about it.
ca7c213 to
69caadd
Compare
|
@oleonardolima renamed and squashed |
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.
I suggested two other changes, other than that it looks good! Thanks for extending the Esplora API.
715e7b7 to
75a5f7b
Compare
|
my bad, missed those the last time, i've squashed them together |
75a5f7b to
9b6bf23
Compare
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.
tACK 9b6bf23
I tested it locally using mempool.space mainnet API and it worked as expected.
It's unrelated to this PR, but CI is failing on the coverage step.
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.
Basically LGTM, mod some comments/nits.
src/lib.rs
Outdated
| ) | ||
| .unwrap(); | ||
|
|
||
| let address_blocking = blocking_client.get_address_stats(&address).unwrap(); |
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.
This is likely flaky as the transaction that we send via the bitcoind RPC will need some time to propagate through the mempool and to get picked up by electrs. We might want to call get_tx or similar in a loop with exponential back-off until we know the txid is available.
Also nit: could renamed these variables, as they are not in fact addresses themselves, but rather address stats.
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.
doesn't the generate_blocks_and_wait handle this?
let _miner = MINER.lock().await;
generate_blocks_and_wait(1);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.
renamed the variables
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.
doesn't the generate_blocks_and_wait handle this?
It does for the block itself, but there is no guarantee the transaction actually made it into the mempool and progated to electrs when we call get_address_stats (prior to generate_blocks_and_wait).
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.
are we doing this on any of the other tests?
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.
No, the other tests don't seem to query Esplora immediately after submitting a new transaction to bitcoind though. electrs only polls for new data in some interval, which can lead to related flakiness in CI in my experience. Here would be an example how to avoid it: https://github.com/lightningdevkit/ldk-node/blob/9e00f357556e5498625515464a89ef7aea14acdf/tests/common/mod.rs#L354-L365
If you don't want to tackle it here, we should probably open an issue for it though, or, granted, wait until we actually see some flakiness.
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.
@tnull I like the idea of waiting to see if we see the flakiness
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.
As the current test state it seems fine, as it's checking for chain_stats summary, which has values only for transactions already on the chain (which should be already covered by generate_blocks_and_wait() fn).
It'd probably be flaky if we're asserting for mempool_stats as well.
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.
I noticed some typos in the recent commits, also left some suggestions.
All the new commits probably should be squashed under the first one, as they touch the same files and are basically typos and documentation improvements.
f9aaf60 to
4d57c58
Compare
|
thanks @oleonardolima merged the typo fixes and squashed it all together |
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.
utACK 4d57c58
It looks good! I left another suggestion to make the documentation equivalent on both async and blocking APIs.
Also, the formatting step is failing on CI, a cargo +nightly fmt --all will probably do.
Once that's fixed I'll give another test and properly tACK it 😁.
10ad0a6 to
3fdd66c
Compare
|
done @oleonardolima |
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.
tACK 3fdd66c
|
@praveenperera You probably need to rebase it, after #110 got merged. @ValuedMammal Could you also take a look at this one, I think it can be merged before #103. |
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.
ACK 3fdd66c
…and `get_address_txns` endpoints
3fdd66cbb185241124e4380b7dbe11f1cb117563 feat(api): add `/address/:address` and `/address/:address/txs` endpoints (Praveen Perera)
Pull request description:
ACKs for top commit:
oleonardolima:
tACK 3fdd66cbb185241124e4380b7dbe11f1cb117563
ValuedMammal:
ACK 3fdd66cbb185241124e4380b7dbe11f1cb117563
Tree-SHA512: b27f06fde5191d4246b075e4a44fbd41310e60f92b4ece2ff8b794ed86e0de6e6e85d982bb969d69f677f72832ff8f2c7963b85607bc4814a5974e19d7e40c9c
No description provided.