Re: Hooking into Faraday connections that have already been built

[Myron Marston]

On Wed, Oct 10, 2012 at 3:45 PM, Harry Wilkinson <hwilk...@mdsol.com> wrote:

Hi,

I have encountered a problem in some tests where some of my HTTP traffic is not getting caught by VCR, and I'm trying to figure out how to fix that.  My app uses a gem that works a little bit like ActiveResource, making web requests through a Ruby API.  That gem uses Faraday to make the requests, using a connection that is built more-or-less at load time.  This all works fine, but it makes the VCR setup interesting.

By the time the VCR hook_into call is made, this Faraday connection has already been built, with its own particular set of middleware.  So the VCR middleware never gets added to this existing Faraday connection.  

I'm trying to figure out the best way to solve this problem - I could try to explicitly rebuild this gem's connection, or I could try to get VCR loaded and configured before this other gem.  But it would also be nice to be able to just have VCR hook into an existing connection.   I don't know for sure if this is possible - I'm no Faraday expert - but from looking at the code it looks like we ought to be able to add handlers to an existing Faraday connection.  And since VCR already has code to add its own handlers when the connection is built, it might make sense if VCR also had code to add its own handlers to an existing Faraday connection.

If you think I've got the wrong idea about any of this, or there's some better way to solve my problems that I haven't noticed, please say so!  Otherwise, does this sound like a feature that would be welcome in VCR?  If I can make it work I could submit a PR.

Thanks.

Harry

Hey Harry,

Thanks for digging in in advance to figure out the source of your issue!

It would certainly be nice if VCR would hook into every faraday connection, but I'm not sure that's possible w/o extensive monkey patching, and the beauty of VCR's integration with Faraday is that it does it all with (virtually) no monkey patching, using Faraday's middleware architecture instead.  I don't want to add additional monkey patching for a case like this.

Just before a Faraday connection is used for the first time, it locks the connection [1] so that not further modifications can be made to the middleware stack.  You might be able to find a way around this, but it would be violating core assumptions the faraday developers have made about the state of their stack and I wouldn't want VCR to mess with that.

In my opinion, the middleware stack is the reason Faraday is awesome, and any good client gem should expose hooks to add your own middlewares.  Does your gem expose those hooks?  If so, you can add VCR's middleware to the stack yourself rather than using `hook_into :faraday`.

Alternately, you can rearrange the order things are loaded in (so that VCR is loaded before your gem), as you mentioned.  I'd also recommend looking into changing the gem so that it doesn't lock the connection at load time...that feels like a code smell to me, as it forces users to require things in a particular order to work correctly.  It would seem better for the faraday connection to be constructed (and memoized) lazily on demand.

HTH,

Myron

[1] https://github.com/technoweenie/faraday/blob/v0.8.4/lib/faraday/connection.rb#L64-81

[hwilk...@mdsol.com]

Thanks for the response Myron.  I didn't meant to pursue anything that required monkey patching, as that is an inevitable maintenance headache.  It's actually going to be a bit easier than I expected to make changes to this particular gem that I need to hook into, so you're right that just making that a little more flexible is going to be the best option.

Harry