Skip to content
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

Can not view details of failed requests #1284

Open
mvastola opened this issue May 21, 2021 · 3 comments
Open

Can not view details of failed requests #1284

mvastola opened this issue May 21, 2021 · 3 comments
Milestone

Comments

@mvastola
Copy link

mvastola commented May 21, 2021

When a request (with or without raise_error) results in a timeout (or another error raised at the adapter level), it is impossible (as far as I know) to retrieve the details of the original request (at least in a way that's compatible with all other HTTP errors).

There should be a way to tell Faraday to never raise an error resulting from a connection (i.e. this should cover all the different timeout errors, socket errors, SSL errors) and instead, in those cases, provide the error in the object returned by Connection#get/#post/etc. (Presumably alongside where the response status/body/headers would be.)

For example, right now I'm developing unit tests for a place we use faraday and I'm realizing there's no easy way to recover information about the request that threw an error if a ruby exception was thrown.

@iMacTia iMacTia added this to the v2.0 milestone May 22, 2021
@iMacTia
Copy link
Member

iMacTia commented May 22, 2021

For context, here are my thoughts on this and how we should tackle it:
#1249 (comment)

@iMacTia iMacTia modified the milestones: v2.0, v3.0 Jul 31, 2021
@iMacTia iMacTia mentioned this issue Jul 31, 2021
32 tasks
@gmcgilvray
Copy link

Pinging this issue to see if anything is in the works to resolve this issue or if anyone has found a workaround.

@iMacTia
Copy link
Member

iMacTia commented Mar 29, 2024

Hi @gmcgilvray, since this issue was opened, we've got #1335 merged which allows you to retrieve the request url.

As for a workaround, the suggestion is still to write a custom middleware and inject it as close as possible to the adapter as discussed here

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

No branches or pull requests

3 participants