Is there a way to cancel an ongoing sync?

[icota]

Specifically with the electrum backend. It locks the DB so during that time it is impossible to fetch a new address.

[notmandatory]

With the pre-1.0 sync there's no way to stop it while it's syncing. But post 1.0 you'll have more control of how and when to sync and store updates. For 1.0 there is a three step process, 1. scan the blockchain for wallet updates, access to Wallet isn't blocked, and 2. apply updates to the in memory Wallet indexes, a quick operation, 3. if any updates changed the Wallet, persist those to your DB, this should also be quick and not block access to the Wallet. The PR #976 includes examples for syncing with electrum and esplora.

[orar]

Considering this discussion, I wrote an SQLx Postgres as a wallet DB right from the SQLite implementation. So I use an sqlx::PgPool where my app is async using tokio.
I often create a new wallet object in a spawn_blocking task and drop the wallet object afterward whenever I need the wallet to sync, generate an address, or start a transaction.

How bad can it be when an address is being generated in a wallet object whereas a wallet sync is ongoing in another wallet object on a different thread?

[bodymindarts]

You may want to checkout this code in bria That also uses sqlx with bdk.
If you construct the tables / queries correctly you can handle the concurrent sync / mutations via row level locks or serialisable transactions in Postgres.

[LLFourn]

Just to note that the redesign of BDK is to stop you having to do these kind of things. in the 1.0.0-alpha releases you can sync without a lock on the wallet.

[orar]

You may want to checkout this code in bria That also uses sqlx with bdk. If you construct the tables / queries correctly you can handle the concurrent sync / mutations via row level locks or serialisable transactions in Postgres.

I find bria implementation very interesting and clean, but I'm feeling lazy to go to that extent.
I resulted to acquire a single connection from the PgPool for every wrapped wallet instance created. Upon a series of testing and pg logs, I realized the important updates are run in a batch transaction. Thus, creating a wallet instance on a PgConnection locked in a transaction is the easiest way out. The risk being having limited wallet instances cos of limited connections. And that's not an issue for my use case.

Just to note that the redesign of BDK is to stop you having to do these kind of things. in the 1.0.0-alpha releases you can sync without a lock on the wallet.

Nice to know. I will try the 1.0.0-alpha.