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
* update reqwest and http crates
remove task_local_extensions
* remove older opentelemetry packages
* remove more legacy and add new otel
* attempt to make features additive
* features are additive
* delete commented out code
* build split
* docs
* more uniform with reqwest::Client
* remove arcs
* slight optimisation
* update readmes
* update changelog
* Add a generic function to the middleware struct for the `Retryable` decision.
The generic function can be used to define custom behaviour to decide whether to retry a request or not.
By default, this function is `Retryable::from_reqwest_response` which is the same as it was before.
* Add a way to create custom retry policies.
A RetryStrategy will dictate what decision will be made based on the result of the sent request.
* Add RetryableStrategy in the `RetryTransientMiddleware` struct instead of the seperate functions
* Add constructor to create a `RetryTransientMiddleware` with a custom `RetryableStrategy`
* Run `cargo fmt`
* Add example code to the `RetryableStrategy` struct
* Run `cargo fmt`
* Updated changelog
* use a trait
* docs
* include latest changes
Co-authored-by: Conrad Ludgate <conrad.ludgate@truelayer.com>
* Adds version function to RequestBuilder impl
Addresses an issue where the Http version of a request cannot be changed when using reqwest_middleware
* Removes function from wasm compiles
---------
Co-authored-by: Jeramy Singleton <wisingle@microsoft.com>
* feat: add `OtelPathNames` for span names
If this extension is provided span names will be `<method> <path name>`.
These path names will include parameter names rather than IDs or other elements that would increase the cardinality.
* doc: update changelog
* refactor: update `known_paths` to return error
* refactor: return `anyhow::Error` instead
This is as `reqwest_middleware::Error` is more focused on handling a
request.
* refactor: Simplify retry middleware in reqwest.
Removed retry limit:
- Remove MAXIMUM_NUMBER_OF_RETRIES metadata and references in middleware.rs
- Correct mispelling: retry_decision to retry_decision in middleware.rs
- Update Retryable matching to only match Retryable::Transient in middleware.rs
- Simplify branching by removing n_past_retries < MAXIMUM_NUMBER_OF_RETRIES condition in middleware.rs
* test: Remove retry cap assertion from test file
remove retry limit assertion test
* feat: wasm32-unknown-unknown support
This replaces task-local-extensions with http's extensions, as http was
already in the dependency closure anyway and the other features of
task-local-extensions (that required an incompatible-with-wasm part of
tokio) were not used anyway.
* feat: have ci check that wasm32-unknown-unknown keeps compiling
* revert back to task-local-extensions
* fix ci
* fix random on wasm
* fix ci again
* bump
---------
Co-authored-by: Conrad Ludgate <conrad.ludgate@truelayer.com>
* Breaking change(macros): require explicit name for tracing middleware
Closes: #52
This is suggested by the Opentelemetry spec, which requires "Therefore,
HTTP client spans SHOULD be using conservative, low cardinality names
formed from the available parameters of an HTTP request, such as "HTTP
{METHOD_NAME}". Instrumentation MUST NOT default to using URI path as
span name, but MAY provide hooks to allow custom logic to override the
default span name.
"
* Permit customisation of otel span names via OtelName
