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

Startup can fail with certain multi-tenancy subwallets [Multi-tenancy] #3030

Closed
jamshale opened this issue Jun 12, 2024 · 7 comments
Closed
Assignees

Comments

@jamshale
Copy link
Contributor

jamshale commented Jun 12, 2024

There was an issue reported here #2922 (review) with the anoncreds upgrade feature. For some reason it is unable to query the subwallet and/or create to subwallet profile.

It needs to handle this scenario correctly.

I have tried to reproduce with sqlite DB and normal sub-wallet and base-wallet setting but have been unable to reproduce the issue so far.

@jamshale jamshale self-assigned this Jun 12, 2024
@ff137
Copy link
Contributor

ff137 commented Jun 12, 2024

Thank you! I'll try modify provision=True and test with that... Will report back tomorrow 👌

@ff137
Copy link
Contributor

ff137 commented Jun 13, 2024

I've tested just with the simple change setting provision to True, but we still get the same error:

Traceback (most recent call last):
aries_askar.error.AskarError: Backend error
Caused by: error returned from database: Request returned an error: database "a8f2692b4e4b4312a9ae696d76643362" does not exist.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/commands/start.py", line 72, in init
    await startup
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/commands/start.py", line 29, in start_app
    await conductor.start()
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/core/conductor.py", line 522, in start
    await self.check_for_wallet_upgrades_in_progress()
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/core/conductor.py", line 846, in check_for_wallet_upgrades_in_progress
    subwallet_profiles = await get_subwallet_profiles_from_storage(
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/utils/profiles.py", line 54, in get_subwallet_profiles_from_storage
    await MultitenantManager(root_profile).get_wallet_profile(
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/multitenant/manager.py", line 85, in get_wallet_profile
    profile, _ = await wallet_config(context, provision=provision)
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/config/wallet.py", line 51, in wallet_config
    profile = await mgr.provision(context, profile_cfg)
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/askar/profile.py", line 293, in provision
    opened = await store_config.open_store(provision=True)
File "/usr/local/lib/python3.9/site-packages/aries_cloudagent/askar/store.py", line 168, in open_store
    raise ProfileError("Error opening store") from err
aries_cloudagent.core.error.ProfileError: Error opening store

It's likely related to some specifics in our config. I'll debug a bit more and see what I can find out

@jamshale
Copy link
Contributor Author

OK. I'll try and replicate it later today with some other configurations. I can't think of anything off the top of my head.

@jamshale
Copy link
Contributor Author

It might be easy to fix by just ignoring the subwallets that can't open their store. All this is doing is resuming an in progress upgrade if interrupted by a restart. It's not very likely to happen. I thought it would be a safe operation but apparently there's a bit more to it then I thought.

@jamshale jamshale changed the title Startup fails with un-provisioned subwallets [Multi-tenancy] Startup can fail with certain multi-tenancy subwallets [Multi-tenancy] Jun 13, 2024
@jamshale
Copy link
Contributor Author

jamshale commented Jun 13, 2024

I've tried to replicate this with normal configurations and haven't been able to.

However, I was able to reproduce something similar by manually deleting a subwallet DB and restarting with the global auto_provision setting set to False (the default).

I feel like there must be something going on with the configurations and DB to cause this problem. However, setting provision to True in the https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/utils/profiles.py#L54 call also prevented the error from happening and re-created the DB.

@jamshale
Copy link
Contributor Author

Could you share your ACAPY_WALLET_STORAGE_CONFIG? Obviously without any sensitive info.

I'm wondering if this has anything to do with the wallet_scheme. I've only tested with the defaults. I can't even remember or find how to configure it without a DatabsePerWallet wallet_scheme.

@jamshale
Copy link
Contributor Author

jamshale commented Jun 20, 2024

I'm going to close this for now as #3048 will prevent this check from crashing on startup. If a more detailed explanation of the scenario that leads to the problem can be produced I can have another look at preventing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants