Capybara: Capybara hangs indefinitely on call to visit method, stuck in process_and_follow_redirects

[tigarcia]

Meta

Capybara Version:
2.8.1
Driver Information (and browser if relevant):
rack-test driver?. I did not set a driver in the config

Expected Behavior

when calling visit root_path, I expect to get a result quickly

Actual Behavior

the rspec test hangs indefinitely when visit is called in the before_each block of the test. Here is the exact code in a feature spec:

  before(:each) do
    visit root_path
  end

This is happening on all feature specs.

I have debugged enough to see that capybara is getting stuck in the following method:

Capybara::RackTest::Browser.process_and_follow_redirects(method#Symbol, path#String, attributes#Hash, env#Hash)

Steps to reproduce

I'm not sure of the exact repo. I'm assuming its a combo of settings and dependencies that contribute to it.

Here is the spec helper I was using:

#require 'capybara/rails'
require 'capybara/rspec'

# This file was generated by the `rails generate rspec:install` command. Conventionally, all
# specs live under a `spec` directory, which RSpec adds to the `$LOAD_PATH`.
# The generated `.rspec` file contains `--require spec_helper` which will cause
# this file to always be loaded, without a need to explicitly require it in any
# files.
#
# Given that it is always loaded, you are encouraged to keep this file as
# light-weight as possible. Requiring heavyweight dependencies from this file
# will add to the boot time of your test suite on EVERY test run, even for an
# individual file that may not need all of that loaded. Instead, consider making
# a separate helper file that requires the additional dependencies and performs
# the additional setup, and require it from the spec files that actually need
# it.
#
# The `.rspec` file also contains a few flags that are not defaults but that
# users commonly want.
#
# See http://rubydoc.info/gems/rspec-core/RSpec/Core/Configuration
RSpec.configure do |config|
  # rspec-expectations config goes here. You can use an alternate
  # assertion/expectation library such as wrong or the stdlib/minitest
  # assertions if you prefer.
  config.expect_with :rspec do |expectations|
    # This option will default to `true` in RSpec 4. It makes the `description`
    # and `failure_message` of custom matchers include text for helper methods
    # defined using `chain`, e.g.:
    #     be_bigger_than(2).and_smaller_than(4).description
    #     # => "be bigger than 2 and smaller than 4"
    # ...rather than:
    #     # => "be bigger than 2"
    expectations.include_chain_clauses_in_custom_matcher_descriptions = true
  end

  config.include Capybara::DSL

  config.before(:each, :type => :request) do
    Capybara.default_host = 'http://localhost'
  end

  # rspec-mocks config goes here. You can use an alternate test double
  # library (such as bogus or mocha) by changing the `mock_with` option here.
  config.mock_with :rspec do |mocks|
    # Prevents you from mocking or stubbing a method that does not exist on
    # a real object. This is generally recommended, and will default to
    # `true` in RSpec 4.
    mocks.verify_partial_doubles = true
  end

  # This option will default to `:apply_to_host_groups` in RSpec 4 (and will
  # have no way to turn it off -- the option exists only for backwards
  # compatibility in RSpec 3). It causes shared context metadata to be
  # inherited by the metadata hash of host groups and examples, rather than
  # triggering implicit auto-inclusion in groups with matching metadata.
  config.shared_context_metadata_behavior = :apply_to_host_groups


  config.disable_monkey_patching!

  if config.files_to_run.one?
    # Use the documentation formatter for detailed output,
    # unless a formatter has already been configured
    # (e.g. via a command-line flag).
    config.default_formatter = 'doc'
  end

  # Print the 3 slowest examples and example groups at the
  # end of the spec run, to help surface which specs are running
  # particularly slow.
  config.profile_examples = 3

  # Run specs in random order to surface order dependencies. If you find an
  # order dependency and want to debug it, you can fix the order by providing
  # the seed, which is printed after each run.
  #     --seed 1234
  config.order = :random

  # Seed global randomization in this process using the `--seed` CLI option.
  # Setting this allows you to use `--seed` to deterministically reproduce
  # test failures related to randomization by passing the same `--seed` value
  # as the one that triggered the failure.
  Kernel.srand config.seed

  ####
  #
  # Database Cleaner Config
  #
  ####
  config.before(:suite) do
    if config.use_transactional_fixtures?
      raise(<<-MSG)
        Delete line `config.use_transactional_fixtures = true` from rails_helper.rb
        (or set it to false) to prevent uncommitted transactions being used in
        JavaScript-dependent specs.

        During testing, the app-under-test that the browser driver connects to
        uses a different database connection to the database connection used by
        the spec. The app's database connection would not be able to access
        uncommitted transaction data setup over the spec's database connection.
      MSG
    end
    DatabaseCleaner.clean_with(:truncation)
  end  

  config.before(:each) do
    DatabaseCleaner.strategy = :transaction
  end

  config.before(:each, type: :feature) do
    # :rack_test driver's Rack app under test shares database connection
    # with the specs, so continue to use transaction strategy for speed.
    driver_shares_db_connection_with_specs = Capybara.current_driver == :rack_test

    if !driver_shares_db_connection_with_specs
      # Driver is probably for an external browser with an app
      # under test that does *not* share a database connection with the
      # specs, so use truncation strategy.
      DatabaseCleaner.strategy = :truncation
    end
  end

  config.before(:each) do
    DatabaseCleaner.start
  end

  config.append_after(:each) do
    DatabaseCleaner.clean
  end
  #
  # End Database cleaner setup
  #
  ####


# The settings below are suggested to provide a good initial experience
# with RSpec, but feel free to customize to your heart's content.
=begin
  # This allows you to limit a spec run to individual examples or groups
  # you care about by tagging them with `:focus` metadata. When nothing
  # is tagged with `:focus`, all examples get run. RSpec also provides
  # aliases for `it`, `describe`, and `context` that include `:focus`
  # metadata: `fit`, `fdescribe` and `fcontext`, respectively.
  config.filter_run_when_matching :focus

  # Allows RSpec to persist some state between runs in order to support
  # the `--only-failures` and `--next-failure` CLI options. We recommend
  # you configure your source control system to ignore this file.
  config.example_status_persistence_file_path = "spec/examples.txt"

  # Limits the available syntax to the non-monkey patched syntax that is
  # recommended. For more details, see:
  #   - http://rspec.info/blog/2012/06/rspecs-new-expectation-syntax/
  #   - http://www.teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/
  #   - http://rspec.info/blog/2014/05/notable-changes-in-rspec-3/#zero-monkey-patching-mode
  # config.disable_monkey_patching!

  # Many RSpec users commonly either run the entire suite or an individual
  # file, and it's useful to allow more verbose output when running an
  # individual spec file.
  if config.files_to_run.one?
    # Use the documentation formatter for detailed output,
    # unless a formatter has already been configured
    # (e.g. via a command-line flag).
    config.default_formatter = 'doc'
  end

  # Print the 10 slowest examples and example groups at the
  # end of the spec run, to help surface which specs are running
  # particularly slow.
  config.profile_examples = 10

  # Run specs in random order to surface order dependencies. If you find an
  # order dependency and want to debug it, you can fix the order by providing
  # the seed, which is printed after each run.
  #     --seed 1234
  config.order = :random

  # Seed global randomization in this process using the `--seed` CLI option.
  # Setting this allows you to use `--seed` to deterministically reproduce
  # test failures related to randomization by passing the same `--seed` value
  # as the one that triggered the failure.
  Kernel.srand config.seed

=end
end

[twalpole]

Are you sure you don't have any debug statements (binding.pry, byebug, etc) left in your apps code?

[twalpole]

Also, please try with a recent release of Capybara.

[twalpole]

And finally, since you're not requiring 'capybara/rails', what have you set Capybara.app to?

[tigarcia]

There are definitely no debug statements. Also, I did bundle update and still have the same issue. On capybara version 2.13.0 now.

[tigarcia]

I never set Capybara.app. I should also mention that this setup has been working for our app. Tests were previously passing, and now they do not finish because they are hanging on the first call to visit. The application is working perfectly fine when I visit the root route by running the server (not when calling rspec).

[twalpole]

The rack_test driver needs an app passed in, since it ignores all hostnames and just calls the app directly. In normal usage this would be set by requiring 'capybara/rails' but you have that commented out. If you're not setting Capybara.app then you would have to be manually managing sessions and driver creation, are you doing that?

[tigarcia]

I don't think I was, but I updated my spec_helper to have the following at the top:

ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'capybara/rails'

I'm still seeing the same issue. It hangs on visit.

[tigarcia]

And the tests have been working in the past with this exact spec_helper (the one I originally posted).

[twalpole]

If it was working previously then there had to be configuration in other files. we will need a reproducible example to diagnose this, otherwise we will have to close this as user configuration error since no one else is experiencing it and it's the most basic of functionality which everyone would be experiencing.

[tigarcia]

Understandable. I'll try to come up with better repro steps. I'm not really sure where to look though. I've debugged all the way into rails and I can't figure out what is blocking it.

[twalpole]

Start with whatever else has been changed in your app recently

[tigarcia]

Thanks for talking this through with me. It turns out that it's not a capybara issue. Our Gemfile didn't have all the gems locked to a specific version and I was able to narrow it down to the gem that was causing the issue. Closing this.

[twalpole]

@tigarcia would you mind mentioning which gem and version it was in case anyone else experiences the same problem

[rjurado01]

I use capybara with chrome headless and experience the same error.
I seems that is a problem with version 64.x of Google Chrome.
I have updated to 65.x beta version and fix the error (also works with 63.x version).

[pschroeder89]

@tigarcia Can you let us know what the gem was?