Panicked in go_online()

[monaka]

A unit test in my wallet is panicked in _go_online().

Here is a message from the runtime.

thread '<unnamed>' panicked at 'running stored runtime: AppLevel(Database(Io(Custom { kind: Other, error: "could not acquire lock on \"/tmp/shiro-wallet/60ec7707/sled.db/db\": Os { code: 11, kind: WouldBlock, message: \"Resource temporarily unavailable\" }" })))', /home/monaka/.cargo/git/checkouts/rgb-lib-b21a551c0f942d1d/d1de142/src/wallet/mod.rs:1693:42

I found /tmp/shiro-wallet/60ec7707/sled.db/db on the test environment.

Referring to your code, the database is accessed in a other thread.

https://github.com/RGB-Tools/rgb-lib/blob/1028e9aff8e72fe79987a85bda9b2abfa5717883/src/wallet/mod.rs#L1693

I'm not sure but I suppose my unit tests are calling go_online() more than twice. I think there is room to avoid or reduce panic.

However, I can fix it to reduce calling go_online() for now. This is a feature request rather than a bug report.

[monaka]

I checked my code again and it may be caused by stored.

1. my modified code calls go_online() just once. 2. I got the same error reported above.

~~I asked about this issue on the stored repository. ~~

Ahh... My bad. My code call go_online() twice...

I keep this issue as a feature request.

[nicbus]

calling go_online() more than once should work and is covered by tests

https://github.com/RGB-Tools/rgb-lib/blob/1028e9aff8e72fe79987a85bda9b2abfa5717883/src/wallet/test/go_online.rs#L16 the success test shows how to call go_online() twice successfully, using the same electrum and proxy URLs

https://github.com/RGB-Tools/rgb-lib/blob/1028e9aff8e72fe79987a85bda9b2abfa5717883/src/wallet/test/go_online.rs#L39 the fail test shows how go_online() returns a specific error (CannotChangeOnline) if called twice with mismatching URLs

it is not supposed to to panic so other issues might be at play

[zoedberg]

@monaka Looking to shiro-backend I think I understood the issue you're facing. When you create more than a wallet on the same data directory and then go online, the second instance will fail doing so since daemons (stored and rgbd) are already running on that data dir.

On rgb-lib we should add a check to prevent this, but it's not trivial so I'm not sure when we're going to do that.

On shiro-backend you should avoid recreating the wallet and going online each time an API is called (not just for this limitation but also for performance reasons, as go_online can be very expensive). I suggest saving the wallet instance in a shared place and reusing it.

[monaka]

@nicbus @zoedberg Thank you for your comments. As I commented, I see this issue is caused by my unexpected API calls.

I close this issue. And I raised #18 instead. I suppose that #18 is an issue under expected calling steps.

I close this issue as invalid. Thank you for your help.

[zoedberg]

@monaka you're welcome. I've just seen #18 and I think I understand why it's failing. Shortly I will answer there too