seanmonstar / reqwest

An easy and powerful Rust HTTP Client
https://docs.rs/reqwest
Apache License 2.0
9.84k stars 1.11k forks source link

Allow to control hyper's thread pool or logging #1506

Open hrxi opened 2 years ago

hrxi commented 2 years ago

Is your feature request related to a problem? Please describe. I'm trying to build a tracing backend that ships logs via HTTPS requests. I want to disable logging for this tracing backend because allowing logging would cause a positive feedback loop where logs cause more logs to be produced indefinitely.

I can disable logging for the thread that reqwest's future is on. Unfortunately, hyper, the backend for this crate, also tokio::spawns some futures, for which I cannot directly control logging. hyper has some way of controlling the spawning of new tasks, and I can use that to disable logging in background threads as well:

use tracing::instrument::WithSubscriber;

struct Executor;

impl hyper::rt::Executor<Pin<Box<dyn Future<Output = ()> + Send>>> for Executor {
    fn execute(&self, fut: Pin<Box<dyn Future<Output = ()> + Send>>) {
        use crate::no_subscriber::NoSubscriber;
        tokio::spawn(fut.with_subscriber(NoSubscriber::default()));
    }
}

builder.executor(Executor);

(Note that NoSubscriber of tracing currently has a bug: https://github.com/tokio-rs/tracing/issues/1999, so you need a copy of its source code to actually stop tracing from logging.)

Describe the solution you'd like Possible solutions:

  1. Expose setting the hyper::rt::Executor directly on reqwest::ClientBuilder.
  2. Create some wrapper trait so you don't expose hyper's trait directly.
  3. Add a setting no_logging on reqwest::ClientBuilder that stops hyper's spawned tasks from logging.
hrxi commented 2 years ago

I'm willing to implement any of these solutions or one that you come up with. :)

gaoqiangz commented 2 years ago
  1. Expose setting the hyper::rt::Executor directly on reqwest::ClientBuilder.

This will be great,also solve this issue https://github.com/hyperium/hyper/issues/2112#issuecomment-576416498.