Allow `update_env/2` function as the option for `Tesla.Middleware.Retry`

[smt116]

The function takes the result and env from the previous attempt and returns a new env for the retry request. It allows supporting "retry with new authorization token" cases.

[smt116]

@yordis, no options were renamed. I've just sorted the list alphabetically for better readability.

[yordis]

🤦🏻‍♂️ .... nevermind ... 🤦🏻‍♂️

[teamon]

What’s the use case for updating the env on retry? If feels a bit weird to add it as an option.

In case of authentication I’d probably write a custom middleware with something like:

case Tesla.run(env, next) do
  {:ok, %{status: 401}} -> 
    env 
    |> Tesla.put_header(…)
    |> Tesla.run(next)
  other -> 
    other
end

[yordis]

@teamon beside that use case, I am trying to find who created an issue or comment or something where the person wanted to log the retries because it was important to him to know how many retries for a given endpoint were happening type of thing ...

For the use 401 use case, I would propose adding a middleware before the retry.

[yordis]

Also this, https://hexdocs.pm/opentelemetry_semantic_conventions/OpenTelemetry.SemanticConventions.Trace.html#http_retry_count/0

I intended to use this PR to try to change the http_retry_count in https://github.com/open-telemetry/opentelemetry-erlang-contrib/blob/main/instrumentation/opentelemetry_tesla/lib/middleware/opentelemetry_tesla_middleware.ex, and teach people how to connect them.

If you expose the OTEL context, you may also want such information.

---

So from my end, two use cases thus far,

1. Somebody asked to be able to log retries so they can collect metrics about it
2. Be able to add http_retry_count to a request.

[teamon]

Maybe Retry middleware should just add retry_attempt counter to env.opts?

[yordis]

Tricky situation, even adding that the OTEL Middleware would be the one concerning OTEL stuff.

• Would that require to fallback to the OTEL middleware?
• Or Would you suggest adding another middleware in front of Retry?

Same for the logger

The tricky bit is the direction of dependencies and the runtime workflow. I am unsure how to accomplish the tasks without introducing coupled middleware to the Retry middleware and the potential complexity and ordering nightmare or opening up the API a bit.

Not sure.

[yordis]

Found the issue https://github.com/elixir-tesla/tesla/issues/578 @egeersoz; maybe you want to participate over here!

[yordis]

Hey there, thank you so much for taking the time to contribute, as @teamon said https://github.com/elixir-tesla/tesla/pull/537#issuecomment-1548363180 I recommend you write a custom middleware related to your authentication needs that reinject the new token.