Middleware: Provide EVEN MORE information to default_value handle

[metaskills]

So #35 added the error to the default value proc. In my work, I want the identifier so I can use that key to get a response from my cache. Would you be open to a pull request for this?

My thoughts would be to pass the env so I could just ask it for the URL. Are there other ways? Has anyone else been interested in making the default value a previous cached request?

cc @dwaller

[sideshowcoder]

Actually I feel like this is already possible to get at with the current setup

require "faraday"
connection = Faraday.new(url: "http://example.com")
response = connection.get "/"

response.env.url

will give you the url, as the response is linked back to the environment in faraday. Does this help?

In general I'm open to extending this as needed if there is more you need to get at, feel free to submit a PR :). Thanks for the feedback by the way, if my response is actually what you need I guess some addition to the readme would be in order.

[metaskills]

Timely reply. So that would work if I did indeed get a response back. But what about the cases where it raised an error, like timeouts? I would still need the env/request right?

[metaskills]

So, let me play with this a bit. I believe I can hook into circuit_open_value method for the request and bring back a cached copy using the request_env[:url]. Using your advice, I can cache replies with a TTL using response.env.url as you mentioned above. Will report back later today. Thanks!

[sideshowcoder]

Yes indeed in case of a timeout response would be nil I guess, so one option would be to actually set the original environment back in this case and wrapping it, that should keep it compatible with the current version. let me know how it works out, I think this is a great usecase and we should support that better, either via adding it to the docs or by working towards a new api to ease that.

[metaskills]

@sideshowcoder Here is what I came up with. I am almost certain some patterns here are not the concern of this gem. But I did want to show where my head was and potential use cases. This implementation assumes:

• Cache write backups for each read, for each unique URL.
• That this middleware is inserted before my raise errors.
• Swallows all errors. Only one that happens is when the cache is empty. This can happen in a few ways and is done to prevent empty JSON consumption further up in the stack.
• There is no cache expiration.

https://gist.github.com/metaskills/c270725651d63dfbdf14

[sideshowcoder]

Looks good, I really like the idea. The one thing I think that needs some investigation is if the injection in the open method would mess with the retry logic in circuitbox, I think not but am not completely confident in it so I think it warrants some extensive testing in this area. Other than that seems like something I would love to provide support for with circuitbox.