Faraday 1.0 order of middlewares different

[olleolleolle]

Our master build is currently failing:

https://travis-ci.org/vcr/vcr/jobs/634140946?utm_medium=notification&utm_source=github_status is a failed build where Faraday 1.0 is in use.

  1) Faraday hook inserts the VCR middleware just before the adapter

     Failure/Error:

       expect(conn.builder.handlers.last(2).map(&:klass)).to eq([

         VCR::Middleware::Faraday,

         Faraday::Adapter::NetHttp

       ])

       expected: [VCR::Middleware::Faraday, Faraday::Adapter::NetHttp]

            got: [Faraday::Response::Logger, VCR::Middleware::Faraday]

       (compared using ==)

       Diff:

       @@ -1,2 +1,2 @@

       -[VCR::Middleware::Faraday, Faraday::Adapter::NetHttp]

       +[Faraday::Response::Logger, VCR::Middleware::Faraday]

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-support-3.9.2/lib/rspec/support.rb:97:in `block in <module:Support>'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-support-3.9.2/lib/rspec/support.rb:106:in `notify_failure'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-expectations-3.9.0/lib/rspec/expectations/fail_with.rb:35:in `fail_with'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-expectations-3.9.0/lib/rspec/expectations/handler.rb:38:in `handle_failure'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-expectations-3.9.0/lib/rspec/expectations/handler.rb:50:in `block in handle_matcher'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-expectations-3.9.0/lib/rspec/expectations/handler.rb:27:in `with_matcher'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-expectations-3.9.0/lib/rspec/expectations/handler.rb:48:in `handle_matcher'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-expectations-3.9.0/lib/rspec/expectations/expectation_target.rb:65:in `to'

     # ./spec/lib/vcr/library_hooks/faraday_spec.rb:13:in `block (2 levels) in <top (required)>'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:257:in `instance_exec'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:257:in `block in run'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:503:in `block in with_around_and_singleton_context_hooks'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:460:in `block in with_around_example_hooks'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/hooks.rb:472:in `block in run'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/hooks.rb:610:in `run_around_example_hooks_for'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/hooks.rb:472:in `run'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:460:in `with_around_example_hooks'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:503:in `with_around_and_singleton_context_hooks'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example.rb:254:in `run'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example_group.rb:633:in `block in run_examples'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example_group.rb:629:in `map'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example_group.rb:629:in `run_examples'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/example_group.rb:595:in `run'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/runner.rb:121:in `block (3 levels) in run_specs'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/runner.rb:121:in `map'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/runner.rb:121:in `block (2 levels) in run_specs'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/configuration.rb:2031:in `with_suite_hooks'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/runner.rb:116:in `block in run_specs'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/reporter.rb:74:in `report'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/runner.rb:115:in `run_specs'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/runner.rb:89:in `run'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/runner.rb:71:in `run'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/lib/rspec/core/runner.rb:45:in `invoke'

     # ./vendor/bundle/ruby/2.4.0/gems/rspec-core-3.9.1/exe/rspec:4:in `<top (required)>'

     # ./vendor/bundle/ruby/2.4.0/bin/rspec:23:in `load'

     # ./vendor/bundle/ruby/2.4.0/bin/rspec:23:in `<main>'

     # ./vendor/bundle/ruby/2.4.0/bin/ruby_executable_hooks:24:in `eval'

     # ./vendor/bundle/ruby/2.4.0/bin/ruby_executable_hooks:24:in `<main>'

Ruby 2.7
Gem master
HTTP ?
Mock ?
Rails ?
Rspec ?

[d-m-u]

Looks like an issue with the adapter index at

vcr/lib/vcr/library_hooks/faraday.rb

Line 32 in 842b2bf

adapter_index ||= handlers.size

is 1 when on faraday-0.9.2 it was 0 because previously the handlers included Faraday::Adapter::NetHttp and it looks like it doesn't now.

[krainboltgreene]

@d-m-u What's this mean for us? I'll be honest, the library adapter part of the code is the one I've looked at least.

[d-m-u]

That makes two of us, I'm pretty unfamiliar with vcr and faraday to be honest. I guess it looks like there's the possibility that vcr will be unable to record the requests for what will now be non-standard configurations, per the warning on

vcr/lib/vcr/library_hooks/faraday.rb

Line 42 in 842b2bf

warn "WARNING: The Faraday connection stack contains middleware after " +

. I didn't have time yet to see where the handlers get set, it kind of feels more like a bug on the faraday side and maybe they should have an issue opened for this?

[d-m-u]

Fixed in #794, see #794 (comment)

[olleolleolle]

Thanks!