Skip to content

Retry middleware: Is there a way to know which request is being retried? #578

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
egeersoz opened this issue May 8, 2023 · 1 comment · Fixed by #608
Closed

Retry middleware: Is there a way to know which request is being retried? #578

egeersoz opened this issue May 8, 2023 · 1 comment · Fixed by #608

Comments

@egeersoz
Copy link

egeersoz commented May 8, 2023

I know we can do this:

should_retry: fn
  {:ok, %{status: status}} when status in [400, 500] -> true
  {:ok, _} -> false
  {:error, _} -> true
end

I'm running into some timeout issues, which from what I can tell emit {:error, :timeout}. The retry logic in that function clause (the third one) work fine, but I also want to log the occurrence in the console in the form of:

The request to #{url} timed out after #{timeout_seconds}. This will be the #{retry_count} time the request is being retried.

Is there a way to add this type of detailed logging?

Use case: I have an importer that imports a whole bunch of data from various APIs, and the total number of possible URLs that data might be fetched from is in the hundreds. I need to know exactly which endpoints are timing out, and how frequently, so I can troubleshoot on the other end.

@yordis
Copy link
Member

yordis commented May 8, 2023

There is no way to accomplish that as of today:

https://github.com/elixir-tesla/tesla/blob/30c3a298bc0de841d8929055429598342ef75573/lib/tesla/middleware/retry.ex#LL90C16-L90C28

Open to accepting a function with two arities passing an object with extra information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants