fix(demo): dispose sqlite persister before folder rename in wallet service#112
fix(demo): dispose sqlite persister before folder rename in wallet service#112Ugarba202 wants to merge 2 commits into
Conversation
Johnosezele
left a comment
There was a problem hiding this comment.
One thing I'd like fixed before merge: in _reseedWalletToFallbackSqlite, the reload after replaceWalletDataWithFallback still lives inside the same try as the persist step. If rename succeeds but _walletLoadRunner throws, the catch runs _walletDisposer(wallet) and fallbackPersister.dispose() again, those are already disposed, and it tries to clean up the fallback dir that's already gone.
Please split that into two phases (persist + failure cleanup, then dispose, rename, reload outside that catch, or use a phase flag) so we don't double dispose on that edge path.
| ); | ||
| } catch (_) { | ||
| _walletDisposer(wallet); | ||
| fallbackPersister.dispose(); |
There was a problem hiding this comment.
If replaceWalletDataWithFallback succeeds but _walletLoadRunner throws, this catch still runs after wallet + fallbackPersister were disposed (lines 614–615).
|
tNACK Tested on Windows 11, the ci still fails with similar error during ( Error output: |
@Johnosezele missed that edge case where it could double dispose on the error path after the rename. I'm splitting the persist step and the reload step into two phases outside that catch block right now so we don't hit that. Will push the fix soon. |
@MusabYK thanks for testing on Windows and sharing the trace! Looks like I'm adding persister tracking to |
Hi @Ugarba202 i took a look and managed to fix the bug from my end, what i'll suggest is you dont need to add persister tracking or disposeWallet() to WalletService to avoid complications, the fix is simpler, you need to explicitly dispose persister in every scope where it is created and handed to a Wallet before the method returns. the bug also exist in the |
Hey @MusabYK, thanks for checking this out! I kept it simple and avoided adding persister tracking or Here is what I updated on the branch:
|
Summary
This PR resolves a Windows-specific filesystem locking bug (
PathAccessException, errno 32) that occurs during SQLite database fallback migration and wallet reseeding inbdk_demo.Context & Root Cause
On Windows, attempting to rename (
Directory.rename) or delete (Directory.delete) a directory while an open file handle exists inside it throwsOS Error: The process cannot access the file because it is being used by another process (errno = 32).During wallet reseeding in
WalletService._reseedWalletToPrimarySqliteand_reseedWalletToFallbackSqlite,Persister.newSqliteheld an active file descriptor onbdk.sqlitewhenWalletStoragePaths.replaceWalletDataWithFallback(folder rename) ordeleteFallbackWalletDatawas called.This change ensures that
persisterandfallbackPersisterare explicitly disposed before any folder renaming or deletion operations occur, matching the existing lifecycle pattern in_migrateWalletToSqliteIfMissing.Related Issues
Checks Ran
just format(Formatted 86 files, zero formatting diffs)just analyze(Zero static analyzer issues across core library)just demo-analyze(No issues found!inbdk_demo)just demo-test(bdk_demounit and service verification suites)