[Bug] Wallet DB Paths incorrect after DB Upgrade from V1 to V2
See original GitHub issueWhat happened?
Think I’ve found a bug in the chia db upgrade
that appears to have been partially fixed in 1.6.0, but introducess new “buggy” behavior.
I have three machines with multiple keys that run full_nodes & wallets. Two were upgraded from V1 to V2 using some version prior to 1.6.0. The pre-upgrade DB Path in the wallet: section of config.yaml was database_path: wallet/db/blockchain_wallet_v1_CHALLENGE_KEY.sqlite. After the upgrade the DB Path was: database_path: wallet/db/blockchain_v2_mainnet.sqlite
. This hard-coded path resulted in all keys having exactly the same balances & transactions, and only one sqllite DB existed in the wallet DB dir.
Doing a clean chia init
results in database_path: wallet/db/blockchain_wallet_v2_CHALLENGE_KEY.sqlite
, and a separate sqllite DB for each key.
Today to test I upgraded the third machine DB to 1.6.0 to V2. Post upgrade the DB path was database_path: wallet/db/blockchain_wallet_v1_CHALLENGE_KEY.sqlite
- the same as the V1 path. It now correctly generates a sqllite DB per key, HOWEVER, the files in the wallet/db path are named blockchain_wallet_v2_r1_mainnet_<key>.sqllite
.
- So in pre 1.6.0 you get a single hard-coded path and all keys used the one hard coded path.
- With 1.6.0 and clean init we get the expected path and DB names.
- With 1.6.0 upgrade it appears the path doesn’t get modified, but the template for the DB names is not honored. The files are
...v2...
vs the expected...v1...
names
Version
1.6.0
What platform are you using?
Linux
What ui mode are you using?
CLI
Relevant log output
No response
Issue Analytics
- State:
- Created a year ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
Just simply
chia db upgrade
On Tue, Sep 27, 2022 at 9:14 AM Arvid Norberg @.***> wrote:
it’s quite the mystery. I can’t find any part of the code that alters the wallet database path. The upgrade command updates the full node database path. The way we handle the config file in general is not great though, so it’s possible for changes to be clobbered if another process writes to the file, failing to first read the most recent changes to it.
I can’t see a way for that issue to cause this symptom though.