reqwest-middleware icon indicating copy to clipboard operation
reqwest-middleware copied to clipboard

Compilation issue with mininal dependencies version

Open ilaborie opened this issue 11 months ago • 1 comments

Bug description

I have a compilation issue with these lines:

use reqwest::header::{HeaderMap, HeaderValue, ACCEPT};
use reqwest::{Client, Response, StatusCode, Url};
use reqwest_middleware::ClientWithMiddleware;
use reqwest_tracing::TracingMiddleware;

// ...

let mut headers = HeaderMap::new();
headers.insert(
   ACCEPT,
   HeaderValue::from_static("application/vnd.schemaregistry.v1+json"),
);
let reqwest_client = Client::builder().default_headers(headers).build()?;
let client = reqwest_middleware::ClientBuilder::new(reqwest_client)
    // Insert the tracing middleware
    .with(TracingMiddleware::default())
    .build();
error[E0277]: the trait bound `TracingMiddleware<DefaultSpanBackend>: reqwest_middleware::Middleware` is not satisfied
  --> schema-registry-api/src/service/mod.rs:52:19
   |
52 |             .with(TracingMiddleware::default())
   |              ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `for<'a> Fn(reqwest::Request, &'a mut http::extensions::Extensions, Next<'a>)` is not implemented for `TracingMiddleware<DefaultSpanBackend>`, which is required by `TracingMiddleware<DefaultSpanBackend>: reqwest_middleware::Middleware`
   |              |
   |              required by a bound introduced by this call
   |
   = note: required for `TracingMiddleware<DefaultSpanBackend>` to implement `reqwest_middleware::Middleware`
note: required by a bound in `reqwest_middleware::ClientBuilder::with`
  --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/reqwest-middleware-0.4.0/src/client.rs:51:12
   |
49 |     pub fn with<M>(self, middleware: M) -> Self
   |            ---- required by a bound in this associated function
50 |     where
51 |         M: Middleware,
   |            ^^^^^^^^^^ required by this bound in `ClientBuilder::with`

For more information about this error, try `rustc --explain E0277`.

With these dependencies

[dependencies]
reqwest = { version = "0.12.9", features = ["json"], default-features = false }
reqwest-middleware = { version = "0.4.0", features = ["json"] }
reqwest-tracing = "0.5.4"

AND when I try to compile with the minimal dependencies versions using cargo +nightly update -Zminimal-versions to update the Cargo.lock file with the minimal versions

See https://github.com/ilaborie/schema-registry-cli/actions/runs/12104246014/job/33747408600

To Reproduce

Should be reproduced with the same dependencies version AND with the cargo +nightly update -Zminimal-versions to set minimal version in the Cargo.lock file.

Expected behavior

Should compile

Environment

  • OS: Gitub Actions ubuntu-latest
  • Rust version stable, today the 1.83.0

Additional context

ilaborie avatar Dec 01 '24 10:12 ilaborie

The minimal version of reqwest-middleware compatible with reqwest-tracing is 0.3.1, but because of the way reqwest-middleware works, all middlewares and the code composing the middlewares to build the client must use the same version of reqwest-middleware.

A similar problem occurs if you try to use reqwest-tracing with reqwest-middleware 0.3 without -Zminimal-versions because cargo update will select reqwest-middleware 0.4 for reqwest-tracing. This case is occurring with stable Rust, not nightly rust like -Zminimal-versions.

The >0.3.0, < 0.5.0 version requirement was supposed to avoid disruptions to consumers (#198), but now it is creating disruptions to consumers because cargo update doesn't understand that the it needs to select a version of reqwest-middleware compatible with both reqwest-tracing and the crate using reqwest-tracing. I wonder if reqwest-tracing could have an optional dependency on reqwest-middleware 0.3 so the same version can work for either or both when enabled, although that would be a breaking change and wouldn't immediately solve things for me because I'm actually seeing this problem with reqwest-tracing being a dependency of a dependency, and requiring a new feature to be enabled for 0.3 compatibility would be a breaking change, so I would need the dependency to update to the new version first.

matt-phylum avatar Dec 04 '24 13:12 matt-phylum