"Cannot drop a runtime in a context where blocking is not allowed" panic in the blocking Client #1017
Comments
|
This is expected (though the panic message used to be a little different and perhaps more helpful...). |
|
Hi! I’m also hitting this. Is there a recommended workaround? Of course, if you know that you’re in an async context, it makes sense It seems like a particularly surprising failure of compositionality for |
wchargin-branch: rust-gcs-logdir wchargin-source: f8b766436143e6faa603ca551c0ceb8813ea829c
|
If the user is in async function, and they are going to be doing something blocking, they should probably do something like Note that it being in debug mode is mostly because this is meant to help you when developing your app, hopefully local or unit testing will alert you to fix it. We hope to eventually be able to add a lint to the compiler to help detect this, see this goal: rust-lang/wg-async#19 |
|
Thanks for the quick response! This is helpful. It still seems strange If you don’t mind, I might send a PR to |
See discussion on seanmonstar#1017. This patch adds documentation to `blocking` at module level and to its `Client::new` and `ClientBuilder::build`, noting that you can’t create or use a blocking client from within an async runtime, and suggesting potential alternatives. Presumably, all the other methods on `Client` also have this property, but hitting the failure mode would require building a `blocking::Client` outside an async runtime and then moving it into a runtime to send requests; seems potentially not worth polluting all the docs. Test Plan: Ran `cargo doc --features blocking` and verified that the links work. wchargin-branch: docs-blocking-no-async wchargin-source: 0eb36352959cd2ca0b19df5836e75230dc619b9d
See discussion on #1017. This patch adds documentation to `blocking` at module level and to its `Client::new` and `ClientBuilder::build`, noting that you can’t create or use a blocking client from within an async runtime, and suggesting potential alternatives. Presumably, all the other methods on `Client` also have this property, but hitting the failure mode would require building a `blocking::Client` outside an async runtime and then moving it into a runtime to send requests; seems potentially not worth polluting all the docs. Test Plan: Ran `cargo doc --features blocking` and verified that the links work. wchargin-branch: docs-blocking-no-async wchargin-source: 0eb36352959cd2ca0b19df5836e75230dc619b9d
|
This is a problem when used with Is is possible to use the current |
|
Hi @tobz1000, I also have the same problem when using |
|
I solved my problem by using let mut file = std::fs::File::create("image.png").unwrap();
let result = spawn_blocking(move || {reqwest::blocking::get("your_image_address.com/image.jpg").unwrap().copy_to(&mut file).unwrap()}).await;Hope it is smth similar to your problem, or to anyone googling this :) |
|
I am using Rocket with blocking routes ( non async functions ) When I use the blocking client inside one of these endpoints it panics. ( release and debug ) . This panic started after upgrading from reqwest 0.10.X to 0.11.X #[macro_use] extern crate rocket;
use rocket::{Build, Rocket, tokio};
#[get("/async")]
async fn index_async() -> &'static str {
let handle = tokio::task::spawn_blocking(|| {
let client = reqwest::blocking::Client::new();
"Hello, world! Async"
});
let res = handle.await.unwrap();
res
}
#[get("/")]
fn index() -> &'static str {
let res = tokio::task::block_in_place(|| {
let client = reqwest::blocking::Client::new();
"Hello, world!"
});
// using the blocking client here will panic
// reqwest::blocking::Client::new()
res
}
#[launch]
fn rocket() -> Rocket<Build> {
rocket::build().mount("/", routes![index, index_async])
}These work arounds seem to work with rocket for async and blocking endpoints. Using the blocking client in a blocking endpoint directly will cause a panic in reqwest version 0.11.X ( not sure why though...) |
|
Using the blocking client in a blocking endpoint directly will cause a panic in reqwest version 0.11.X ( not sure why though...) |
|
@ta32 thanks for the tip. This still happens in |
- parse_json now async - download_file now async - fixed crash in download_file where tokio runtime is killed (seanmonstar/reqwest#1017) - make backend use one large async block instead of many small ones, allowing for actual async instead of just blocking - Fix issue where GUI would block waiting for backend - (Related to above) now using tokio::sync::mutex instead of std::sync::mutex - New ContinueLock Macro
- parse_json now async - download_file now async - fixed crash in download_file where tokio runtime is killed (seanmonstar/reqwest#1017) - make backend use one large async block instead of many small ones, allowing for actual async instead of just blocking - Remove old dependencies - Fix issue where GUI would block waiting for backend - (Related to above) now using tokio::sync::mutex instead of std::sync::mutex - New ContinueLock Macro
See discussion on seanmonstar#1017. This patch adds documentation to `blocking` at module level and to its `Client::new` and `ClientBuilder::build`, noting that you can’t create or use a blocking client from within an async runtime, and suggesting potential alternatives. Presumably, all the other methods on `Client` also have this property, but hitting the failure mode would require building a `blocking::Client` outside an async runtime and then moving it into a runtime to send requests; seems potentially not worth polluting all the docs. Test Plan: Ran `cargo doc --features blocking` and verified that the links work. wchargin-branch: docs-blocking-no-async wchargin-source: 0eb36352959cd2ca0b19df5836e75230dc619b9d
Hi!
I was working in async context with the blocking reqwest Client with tokio runtime, and it panics every time. Now, I don't know tokio internals so I can't tell whether this is a reqwest or a tokio issue.
This is not critical and I will simply switch to the async client, however I want to report this.
This happens on Windows 10 and on WSL 2. Here's a minified example.
Thank you.
The text was updated successfully, but these errors were encountered: