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

Add get_address_stats and get_address_txns endpoints #104

Merged
merged 1 commit into from
Nov 17, 2024

Conversation

praveenperera
Copy link
Contributor

No description provided.

src/async.rs Outdated Show resolved Hide resolved
src/api.rs Outdated Show resolved Hide resolved
@coveralls
Copy link

Pull Request Test Coverage Report for Build 11334093933

Details

  • 98 of 100 (98.0%) changed or added relevant lines in 4 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.8%) to 88.846%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/async.rs 13 14 92.86%
src/blocking.rs 13 14 92.86%
Totals Coverage Status
Change from base Build 11054999770: 0.8%
Covered Lines: 1139
Relevant Lines: 1282

💛 - Coveralls

@praveenperera
Copy link
Contributor Author

@oleonardolima addressed the comments, naming is hard I went with AddressTxnSummary for the shared struct name

Copy link
Collaborator

@oleonardolima oleonardolima left a 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

src/api.rs Outdated Show resolved Hide resolved
pub mempool_stats: AddressTxnSummary,
}

#[derive(Debug, Copy, Clone, PartialEq, Eq, Deserialize)]
Copy link
Collaborator

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?

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 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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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 ?

Copy link
Collaborator

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.

src/async.rs Outdated Show resolved Hide resolved
src/async.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
@praveenperera
Copy link
Contributor Author

@oleonardolima renamed and squashed

Copy link
Collaborator

@oleonardolima oleonardolima left a 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.

src/async.rs Outdated Show resolved Hide resolved
src/blocking.rs Outdated Show resolved Hide resolved
@praveenperera
Copy link
Contributor Author

my bad, missed those the last time, i've squashed them together

Copy link
Collaborator

@oleonardolima oleonardolima left a 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.

Copy link
Contributor

@tnull tnull left a 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/api.rs Show resolved Hide resolved
src/blocking.rs Outdated Show resolved Hide resolved
src/blocking.rs Show resolved Hide resolved
src/lib.rs Outdated
)
.unwrap();

let address_blocking = blocking_client.get_address_stats(&address).unwrap();
Copy link
Contributor

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.

Copy link
Contributor Author

@praveenperera praveenperera Oct 29, 2024

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);

Copy link
Contributor Author

@praveenperera praveenperera Oct 29, 2024

Choose a reason for hiding this comment

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

renamed the variables

Copy link
Contributor

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).

Copy link
Contributor Author

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?

Copy link
Contributor

@tnull tnull Oct 31, 2024

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.

Copy link
Contributor Author

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

Copy link
Collaborator

@oleonardolima oleonardolima Oct 31, 2024

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.

Copy link
Collaborator

@oleonardolima oleonardolima left a 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.

src/api.rs Outdated Show resolved Hide resolved
src/api.rs Outdated Show resolved Hide resolved
src/api.rs Outdated Show resolved Hide resolved
src/api.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
@praveenperera praveenperera force-pushed the get-address-info branch 2 times, most recently from f9aaf60 to 4d57c58 Compare November 3, 2024 15:13
@praveenperera
Copy link
Contributor Author

thanks @oleonardolima merged the typo fixes and squashed it all together

Copy link
Collaborator

@oleonardolima oleonardolima left a 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 😁.

src/async.rs Outdated Show resolved Hide resolved
@praveenperera
Copy link
Contributor Author

done @oleonardolima

Copy link
Collaborator

@oleonardolima oleonardolima left a comment

Choose a reason for hiding this comment

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

tACK 3fdd66c

@oleonardolima
Copy link
Collaborator

@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.

Copy link
Contributor

@ValuedMammal ValuedMammal left a comment

Choose a reason for hiding this comment

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

ACK 3fdd66c

@ValuedMammal ValuedMammal merged commit 9fcaf01 into bitcoindevkit:master Nov 17, 2024
3 of 25 checks passed
@praveenperera praveenperera deleted the get-address-info branch November 17, 2024 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants