Not working without Tokio. If not meant to, not clear enough.

[esdevver]

I will preface by saying I understand how entrenched the async ecosystem is for rust, so I understand if this crate doesn't intend to support non-tokio runtimes.

I enjoy using this crate, and it works fine with Tokio. When I try to run it with a different runtime, it doesn't work.

It hasn't worked with the smol::block_on runtime, nor my own humble block_on function.

See this snippet:

fn main() {
    smol::block_on(async {
        let response = reqwest::get("https://example.com/").await.unwrap();
        let text = response.text().await.unwrap();
        print!("{text}");
    });
}

This example fails:

thread 'main' panicked at /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/hyper-util-0.1.14/src/client/legacy/connect/dns.rs:119:24:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: tokio::runtime::scheduler::Handle::current::panic_cold_display
   3: tokio::runtime::handle::Handle::current
   4: tokio::runtime::blocking::pool::spawn_blocking
   5: <reqwest::dns::gai::GaiResolver as reqwest::dns::resolve::Resolve>::resolve::{{closure}}
   6: <hyper_util::client::legacy::connect::http::HttpConnector<R> as tower_service::Service<http::uri::Uri>>::call::{{closure}}
   7: <hyper_tls::client::HttpsConnector<T> as tower_service::Service<http::uri::Uri>>::call::{{closure}}
   8: reqwest::connect::ConnectorService::connect_with_maybe_proxy::{{closure}}
   9: reqwest::connect::with_timeout::{{closure}}
  10: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
  11: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
  12: <futures_util::future::try_future::try_flatten::TryFlatten<Fut,<Fut as futures_core::future::TryFuture>::Ok> as core::future::future::Future>::poll
  13: <hyper_util::common::lazy::Lazy<F,R> as core::future::future::Future>::poll
  14: <futures_util::future::select::Select<A,B> as core::future::future::Future>::poll
  15: hyper_util::client::legacy::client::Client<C,B>::send_request::{{closure}}
  16: <hyper_util::client::legacy::client::ResponseFuture as core::future::future::Future>::poll
  17: <reqwest::async_impl::client::HyperService as tower_service::Service<http::request::Request<reqwest::async_impl::body::Body>>>::call::{{closure}}
  18: <tower_http::follow_redirect::ResponseFuture<S,ReqBody,P> as core::future::future::Future>::poll
  19: <reqwest::async_impl::client::PendingRequest as core::future::future::Future>::poll
  20: <reqwest::async_impl::client::Pending as core::future::future::Future>::poll
  21: std::thread::local::LocalKey<T>::with
  22: async_io::driver::block_on
  23: reqwest_fun::main

I think this has something to do with the DNS resolver using tokio primitives, but my investigation isn't so thorough.

Resolution?

I would love for this crate to work outside of tokio contexts. I'm not sure if this failure is a regression or intended behaviour.

If this crate requires to be ran in a tokio context, it should be documented better in the README and crates.io page.
I took it to be runtime-agnostic.

[0x676e67]

This crate does not currently support other async runtimes.

[Xuanwo]

Technically, hyper can run on other runtimes. So it's possible for reqwest to abstract such a trait for runtime switching. But I'm not sure if it worths.

One benefit from my perspective is that we can ensure reqwest spawns tasks on a dedicated runtime. This is useful even if we only have support for Tokio.