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.

Sign up for GitHub

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

Jump to bottom

Consider Typing Errors for Requests with Nil Responses #172

Open
jamesross3 opened this issue Apr 27, 2021 · 4 comments
Open

Consider Typing Errors for Requests with Nil Responses #172

jamesross3 opened this issue Apr 27, 2021 · 4 comments

Comments

@jamesross3
Copy link
Contributor

jamesross3 commented Apr 27, 2021 •
edited
Loading

There are some error cases for requests where the response is nil; these cases fall outside the scope of the existing error decoder middleware implementation. Examples of errors like this are:

  • dial timeout
  • timeout exceeded while awaiting headers
  • DNS lookup no such host
  • certificate signed by unknown authority

Ideally, CGR provides some methods that enable us to identify these errors (similar to typing conjure errors / attaching status codes to errors)
@jamesross3
Copy link
Contributor Author

@nmiyake / @tabboud / @bmoylan / @whickman for opinions here

@bmoylan
Copy link
Contributor

bmoylan commented Apr 27, 2021

Yeah I would be very supportive of this. The errors coming out of the standard library are almost all well-typed, so this conversion should be relatively straightforward (and can grow over time if we don't hit 100% coverage in the first version).

@bmoylan bmoylan closed this as completed Apr 27, 2021
@bmoylan bmoylan reopened this Apr 27, 2021
@tabboud
Copy link
Contributor

tabboud commented Jun 16, 2021

Definitely agree that this would be a valuable addition!

Similarly, @bmoylan just added a way to identify Timeout errors and tag them in the metrics middleware.

I would be fully supportive of adding a way to wire these errors back through so clients could use something like errors.Is with well defined types.

@jamesross3
Copy link
Contributor Author

also interested in whether these error types should affect our existing retry behavior here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@codekarma @bmoylan @tabboud @jamesross3