-
Notifications
You must be signed in to change notification settings - Fork 47
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
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
No description provided.