-
Notifications
You must be signed in to change notification settings - Fork 114
Clean up and modularize chain syncing logic #598
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
Clean up and modularize chain syncing logic #598
Conversation
👋 Thanks for assigning @joostjager as a reviewer! |
src/chain/mod.rs
Outdated
@@ -697,118 +650,8 @@ impl ChainSource { | |||
// etc.) | |||
pub(crate) async fn sync_onchain_wallet(&self) -> Result<(), Error> { | |||
match &self.kind { | |||
ChainSourceKind::Esplora { |
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.
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.
Hmm, will play around with that a bit. Maybe it makes sense to first move everything into individual impl
blocks beneath the original method before joining all in the new location.
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 now went ahead and introduced intermittent impl
blocks, and split the commits introducing the new chain source types and moving them to the dedicated modules. All of this should make for a considerable improvement, especially when reviewed via git diff --color-moved --ignore-all-space
. I think there are some areas where git diff
is still tripping, but I honestly don't know how to improve things further there.
Now pushed this new rewrite, which amounted to an net diff that is almost 0 (just moved a single helper method to a more reasonable location in the process).
We introduce a new `ChainSourceKind` that is held as a field by `ChainSource`, which better encapsulates the chain syncing logic, and in future commits allows us to move some common fields to `ChainSource`.
.. in the hopes of making the git diff more readable going forward, we break up the `ChainSource` impl block.
e966cc9
to
d39869a
Compare
We refactor our `ChainSource` logic and move out the Esplora code into a new object.
d39869a
to
c6a45c1
Compare
We refactor our `ChainSource` logic and move out the Electrum code into a new object.
We refactor our `ChainSource` logic and move out the Bitcoind code into a new object.
c6a45c1
to
f82eec4
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.
This PR shows a really nice decomposition / clean up. I think it was worth it.
The only real comment/question that I have is whether ChainSource
is still needed? It is now mainly a pass through and I was wondering if that could be replaced by a trait?
src/chain/mod.rs
Outdated
logger, | ||
"Successfully broadcast transaction {}", | ||
txid | ||
self.logger, |
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.
Glad you did this somewhat artificial commit struct. Very easy to ascertain that it's still the same.
src/chain/electrum.rs
Outdated
@@ -42,7 +42,83 @@ const BDK_ELECTRUM_CLIENT_BATCH_SIZE: usize = 5; | |||
const ELECTRUM_CLIENT_NUM_RETRIES: u8 = 3; | |||
const ELECTRUM_CLIENT_TIMEOUT_SECS: u8 = 10; | |||
|
|||
pub(crate) struct ElectrumRuntimeClient { | |||
pub(super) enum ElectrumRuntimeStatus { |
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.
Maybe the diff would improve a bit if you left this at roughly the same location as where it was.
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 not sure I moved this much, but rather moved other things around that have git
conclude that this was moved. Not sure it's worth experimenting further, I already did a few iterations until I reached the current state^^
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, fair. Current state is already 90% of the win, if not 100% given diff limits.
Ah, I don't think we can due to how different the transaction vs. block-polling-based chain sources are. If we'd introduce two traits for them, we'd still need an adaptor that would forward to the right implementation. |
.. now that we don't need them anymore for review, we drop the extra `impl` blocks again.
f82eec4
to
7cb1d34
Compare
I think I'm gonna land this, will see to get a PR with follow-ups up soon. |
I would think that something like But the actual logic is now separated, so goal achieved. |
We intended to modularize and clean up our chain sync since quite a while. Here, we finally do it by introducing a new
ChainSourceKind
type and moving the respective syncing logic to newEsploraChainSource
,ElectrumChainSource
, andBitcoindChainSource
objects in the respective modules.This is a rather large refactor, but 99% of the changes are code moves.
Additional cleanup steps / minor fixes will be coming up, but given the PR size I'll probably open a follow-up for them.