-
Notifications
You must be signed in to change notification settings - Fork 322
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
Allow Features to handle ConnectionErrors #547
Comments
I'm not sure I understand why existing code won't work. You can log request before it has been sent. Not sure what benefits |
Currently, you can configure an instance using the Logging feature, and wherever you use it, you will see a Request logged, and then the corresponding Response. The callsites dont have to know about the logging, it happens transparently by the You would have to do something like this, for every call:
Alternatively, you can add the |
I still don't think it's a good idea to introduce the change that will be useful only for logging feature. |
I got the impression that the |
@ixti I think the issue is that there's http-level errors that do generate a response that the Features can "see", but there's another class of errors below the http level (connection errors, timeouts, dns, etc...) that don't ever generate an http response. Since (i think) http.rb just raises an exception in that case, there's no visibility from within the features that it happened. In rack-style middlewares, since each one calls the next in a nested block fashion, each gets an opportunity to rescue the exception and do something with it (log then re-raise, handle it and render an error page, etc...). But those style have the giant nested callstack issues, which I know @tarcieri is pretty strongly against. It does seem useful for logging and instrumentation for the other class of errors to be visible somehow. |
@paul can't you implement Rack-style middleware as a feature? possibly with some modifications to the existing feature code (which would permit the general pattern it seems is desired in this PR) I'm not completely against the concept, I just look at something like Faraday as being very slow because every single request goes through multiple middlewares by default. I think it's fine to have middleware optional, so long as it's off-by-default so the default case is still speedy. |
This addresses httprb#547 It allows a Feature to implement an on_error handler so that it has a chance to react to Requests that never get a Response.
This addresses httprb#547 It allows a Feature to implement an on_error handler so that it has a chance to react to Requests that never get a Response.
This addresses httprb#547 It allows a Feature to implement an on_error handler so that it has a chance to react to Requests that never get a Response.
This addresses httprb#547 It allows a Feature to implement an on_error handler so that it has a chance to react to Requests that never get a Response.
This addresses httprb#547 It allows a Feature to implement an on_error handler so that it has a chance to react to Requests that never get a Response.
This addresses httprb#547 It allows a Feature to implement an on_error handler so that it has a chance to react to Requests that never get a Response. > Extracted the build_response method to stay under the rubocop enforced method length limit.
This addresses httprb#547 It allows a Feature to implement an on_error handler so that it has a chance to react to Requests that never get a Response. > Extracted the build_response method to stay under the rubocop enforced method length limit.
This addresses #547 It allows a Feature to implement an on_error handler so that it has a chance to react to Requests that never get a Response. > Extracted the build_response method to stay under the rubocop enforced method length limit.
An obvious use case for the
Feature
extension point is for logging/instrumenting (#499). This allows you to log request details, and the corresponding response. However, if the connection fails (timeout, DNS lookup failure, etc), you only get a chance to log the request - never the response. Someone looking at the logs will not know what happened to the request.I propose adding the
Feature#on_error
hook, so that logging/instrumenting extensions get a chance to log errors. It could be added in a backward compatible way, so that all existingFeature
implementations still work.Something like this:
The feature
on_error
callback gets access to theRequest
and theConnectionError
(or it could be a broader error).I can put together a PR if we come to agreement on the behavior.
The text was updated successfully, but these errors were encountered: