Hi,
I'd like to ask for new releases for the middleware crates: reqwest-middleware 0.4.0, reqwest-retry 0.7.0 and reqwest-tracing 0.5.4.
In [uv](https://github.com/astral-sh/uv), we're currently using a git dependency for https://github.com/TrueLayer/reqwest-middleware/pull/159, and we'd like to move to a crates.io dependency (https://github.com/astral-sh/uv/issues/8932).
I've bump reqwest-middleware and reqwest-retry according to being breaking changes in the error type, while requiring reqwest-middleware `>0.3.0, <0.5.0` in reqwest-retry and reqwest-tracing for minimal downstream disruption.
waiting on #175 & #176 to fix issues with the build
Recently a [change was introduced that did not compile](4a2b3f335e (r1689595502)) #167.
This was not caught by our CI becuase the feature was not enabled when building in CI.
This change ensures that every possible feature combination is attempted when running tests and clippy in CI. This adds up to 50 attempts for all of our features accross the three crates in this repo. This doesn't take too long since they share build cache.
```
error: doc list item missing indentation
Error: --> reqwest-retry/src/middleware.rs:62:4
|
62 | /// `Body`'s `From<String>` or `From<Bytes>` implementations.
| ^
|
= help: if this is supposed to be its own paragraph, add a blank line
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
= note: `-D clippy::doc-lazy-continuation` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::doc_lazy_continuation)]`
help: indent this line
|
62 | /// `Body`'s `From<String>` or `From<Bytes>` implementations.
| ++
error: doc list item missing indentation
Error: --> reqwest-retry/src/middleware.rs:65:4
|
65 | /// source directly, avoiding the issue of streaming requests not being clonable.
| ^
|
= help: if this is supposed to be its own paragraph, add a blank line
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation
help: indent this line
|
65 | /// source directly, avoiding the issue of streaming requests not being clonable.
| ++
error: could not compile `reqwest-retry` (lib) due to 2 previous errors
```
* Add feature flag for deprecated fields
* revert editor format
* rename flag
* remove unnecessary cfg not
* add comment and publish old and new attributes on request_span macro
* add comment
* update changelog
* Update reqwest-tracing/CHANGELOG.md
Co-authored-by: Ethan Brierley <ethanboxx@gmail.com>
* bump version
---------
Co-authored-by: Ethan Brierley <ethanboxx@gmail.com>
* chore: bump minor version for `reqwest-retry`
Breaking change introduced in https://github.com/TrueLayer/reqwest-middleware/pull/155
* chore: bump patch version for `reqwest-middlware`
* fix: `opentelemetry` item in wrong changelog
* chore: bump patch version for `reqwest-tracing`
* Re-export reqwest crate
In a large project, it's not unheard of for multiple mutually-incompatible versions of a major crate like `reqwest` to end up in the mix. By re-exporting the version of `reqwest` used by `reqwest-middleware`, we can be sure we're referring to the *correct* `reqwest`, rather than some other, incompatible, `reqwest`.
* Update CHANGELOG.md
---------
Co-authored-by: Ethan Brierley <ethanboxx@gmail.com>
fixes#139
There are other potential long term solutions listed [here](https://github.com/TrueLayer/reqwest-middleware/issues/139#issuecomment-2045946644)
> I didn't put much thought into it. Internally there used to be a `Box<[Arc<dyn Middleware>]>` which is cloned about quite often.
>
> * https://docs.rs/reqwest-middleware/0.2.5/src/reqwest_middleware/client.rs.html#87
> * https://docs.rs/reqwest-middleware/0.2.5/src/reqwest_middleware/client.rs.html#139
>
> Because of all the cloning, I decided to flip it to be `Arc<Box>` instead of `Box<Arc>`.
>
> I see three solutions here.
>
> 1. The one I'd lean towards is `Arc<Arc>` even if it's a bit silly, but prevents extra unnecessary allocations on each request.
> 2. An alternative is to implement Middleware for Arc and then you can use the regular with(...) api. This would mean there's an extra box around your middleware
> 3. Revert this particular change
In the short term, I think it's best to go with option 3. This will unblock the next release. We can consider the other options for future releasees
