support tokio async runtimes

[monaka]

Hello,

I'm working to create a wallet-backend.
And I'm getting one test failure.
All other tests are passed.
I suppose it is required to call a shutdown code after I call Wallet::new().
How can I shut down my wallet safely?

test wallet::tests::test_get ... FAILED

failures:

---- wallet::tests::test_get stdout ----
thread 'wallet::tests::test_get' panicked at 'Cannot drop a runtime in a context where blocking is not allowed. This happens when a runtime is dropped from within an asynchronous context.', /home/monaka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/runtime/blocking/shutdown.rs:51:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[monaka]

My code is there: https://github.com/diamondhands-dev/shiro-backend/blob/03e4641da649e567484703eec30d9e34e1941632/src/wallet/mod.rs#L15-L36

[monaka]

I'm not sure but this issue may be caused by using blocking APIs in ConsignmentProxy.
I'm going to create patches.

[zoedberg]

Calling shutdown should not be necessary after calling new. Sometimes tests can hang if an expect/unwrap/unreachable is encountered during test execution, but that should mean that something is wrong (code or test). Currently there is a known bug (RGB-WG/rgb-node#208) that sometimes can cause the tests to hang.

We are still looking for a way to shutdown the rgb-node daemon process though. When that will be possible we could provide an rgb-lib method to shutdown.

About the blocking calls to the proxy, I don't think those are the issue here and moreover we need them to be blocking

[monaka]

I suppose this issue is not related to RGB-WG/rgb-node#208.
The root cause looks:

• My app is built with Tokio asynchronous framework.
• ConsignmentProxy uses reqwest::blocking module.

reqwest::blocking uses tokio::runtime.
https://github.com/seanmonstar/reqwest/blob/231b18f83572836c674404b33cb1ca8b35ca3e36/src/blocking/client.rs#L973
So my app and rgb-lib conflicts.

I'm inspecting how to fix the conflict with no API breakage.

[zoedberg]

Sorry, I've misread the logs, you're right about conflicts between reqwest blocking and tokio async. Have you tried this solution seanmonstar/reqwest#1017 (comment) ?

[monaka]

@zoedberg Thank you for your suggestion.
But unfortunately, it looks that spawn_blocking doesn't help this issue.
I attach a part of the error message.

error: generator cannot be sent between threads safely
   --> src/wallet/mod.rs:125:35
    |
125 |         let resp = spawn_blocking(move || test::call_service(&app, req)).await;
    |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ generator is not `Send`
    |
    = help: within `impl std::future::Future<Output = <impl actix_web::dev::Service<actix_http::requests::request::Request, Response = ServiceResponse, Error = actix_web::Error> as actix_web::dev::Service<actix_http::requests::request::Request>>::Response>`, the trait `Send` is not implemented for `<impl actix_web::dev::Service<actix_http::requests::request::Request, Response = ServiceResponse, Error = actix_web::Error> as actix_web::dev::Service<actix_http::requests::request::Request>>::Future`

[zoedberg]

@monaka Please give a look at https://github.com/RGB-Tools/rgb-lib/tree/reqwest_async , I've switched to using the async version of reqwest and hence removed its blocking feature that should be causing your issue. If you can please confirm that this fixes your issue, I will then merge this in master.

[monaka]

@zoedberg Thank you for your kind support.
All my tests with https://github.com/RGB-Tools/rgb-lib/tree/reqwest_async are passed.
Please merge your patch to master.

[nicbus]

merged in master

[monaka]

Let me re-open this.
I had the same issue in another code.

I attach a part of the log. (Guess it might be useless...).

thread 'main' panicked at 'Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.', /home/monaka/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/runtime/scheduler/current_thread.rs:516:26

My failed test calls go_online().
I'm not sure but this case may be caused by dependent libs.

[monaka]

Just guess but it may be caused by this line.

rgb-lib/src/wallet/mod.rs

Line 1424 in b0dc38c

std::thread::sleep(Duration::from_millis(500));

[nicbus]

could you please provide the code to reproduce the issue? if you can't share the code, a minimal example is fine as well

[monaka]

@nicbus Thank you for your response. I pushed my code public.
https://github.com/diamondhands-dev/shiro-backend/blob/c794afe8af509088bb202e2410c6a67f51b45eed/src/wallet/go_online.rs#L54-L89

[monaka]

I found some thread::spawn in _go_online.

rgb-lib/src/wallet/mod.rs

Line 1394 in b0dc38c

thread::spawn(move || {

rgb-lib/src/wallet/mod.rs

Line 1407 in b0dc38c

thread::spawn(move || {

Just guess but I think they will conflict with Tokio.

[monaka]

How to reproduce:

rustup update
rm -fr /tmp/shiro-wallet
mkdir -p /tmp/shiro-wallet
git clone https://github.com/diamondhands-dev/shiro-backend.git -b pr-go_online-PUT-endpoint
cd shiro-backend/
docker ps -aq | xargs docker kill
docker system prune --force
test-mocks/start_services.sh
RUST_TEST_THREADS=1 BITCOIN_NETWORK_NAME=regtest cargo test

$ rustup -V
rustup 1.25.1 (bb60b1e89 2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.65.0 (897e37553 2022-11-02)`

[monaka]

I inspected this issue a little bit deeper.
I suppose it is not caused by std::thread::{sleep,spawn} but a nested block_on call.

1. Actix-web calls tokio::runtime::scheduler::current_thread::CurrentThread::block_on().
2. my async block calls rgb_lib::wallet::Wallet::go_online().
3. The proxy code in rgb-lib calls block_on() same as above.
4. The test failed by thread 'main' panicked at 'Cannot start a runtime from within a runtime.

[monaka]

Just a guess but this issue can be fixed by using tokio::task::spawn_blocking ?
I'm checking now.

[monaka]

Just a guess but this issue can be fixed by using tokio::task::spawn_blocking ?

Bingo.

It can be resolved by using spawn_blocking (in tokio::task or actix_web::rt::task).

@nicbus @zoedberg This issue can be resolved on my appication side.
I close this again. Thank you for your kind support.

[zoedberg]

@monaka I have a doubt that this issue could have been solved using spawn_blocking since the beginning. Could you please push your latest shiro-backend code (on the main branch tests still fail) so that I can do some experiments? I would be really happy if we could revert 5211dd8

[monaka]

@zoedberg Surely CI builds on shiro-backend (main branch) is failing.
But it is just caused by Codecov and all tests are passed now.
I agree it is reasonable to revert 5211dd8 even though some additional fixes are required to shiro-backend.