Skip to content
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

Latest version of chrome causes capybara specs to fail with Net::ReadTimeout #2181

Closed
superchris opened this issue Apr 29, 2019 · 37 comments

Comments

@superchris
Copy link

commented Apr 29, 2019

New version of chrome (74) hangs and eventually dies with Net::ReadTimeout. Downgrading to 73 fixes the issue.

Meta

Capybara Version: 3.4.0

Driver Information (and browser if relevant):
Chrome 7.

Actual Behavior

Specs work.

Steps to reproduce

Run any javascript spec

@iwz

This comment has been minimized.

Copy link

commented Apr 29, 2019

Also experiencing this on Capybara 2.18.0 (Rails 3.2). We're using the webdrivers 3.8.0 gem to get the correct version of chromedriver for our currently installed version of Chrome (74). When running capybara :js tests, we get many Net::ReadTimeout errors and the tests fail.

On macOS, we are able to work around this by following these steps:

  • Remove chrome
  • download v 72 here (https://google-chrome.en.uptodown.com/mac/old) (cannot find a version of Chrome 73 anywhere...)
  • run sudo chmod -R 000 ~/Library/Google to prevent chrome from having permissions to execute the updater script, and it can’t update itself any more (unless you run sudo chmod -R 755 ~/Library/Google and allow it to).
@elliterate

This comment has been minimized.

Copy link
Contributor

commented Apr 29, 2019

@bgwilson87

This comment has been minimized.

Copy link

commented Apr 29, 2019

Sample failure, using rails 5.0.7.2:

Net::ReadTimeout:
  Net::ReadTimeout
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/selenium-webdriver-3.142.0/lib/selenium/webdriver/remote/http/default.rb:129:in `response_for'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/selenium-webdriver-3.142.0/lib/selenium/webdriver/remote/http/default.rb:82:in `request'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/selenium-webdriver-3.142.0/lib/selenium/webdriver/remote/http/common.rb:64:in `call'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/selenium-webdriver-3.142.0/lib/selenium/webdriver/remote/bridge.rb:167:in `execute'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/selenium-webdriver-3.142.0/lib/selenium/webdriver/remote/oss/bridge.rb:587:in `execute'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/selenium-webdriver-3.142.0/lib/selenium/webdriver/remote/oss/bridge.rb:154:in `window_handles'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/selenium-webdriver-3.142.0/lib/selenium/webdriver/common/driver.rb:187:in `window_handles'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/capybara-3.18.0/lib/capybara/selenium/driver.rb:192:in `window_handles'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/capybara-3.18.0/lib/capybara/selenium/driver_specializations/chrome_driver.rb:34:in `reset!'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/capybara-3.18.0/lib/capybara/session.rb:128:in `reset!'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/capybara-3.18.0/lib/capybara.rb:315:in `block in reset_sessions!'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/capybara-3.18.0/lib/capybara.rb:315:in `reverse_each'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/capybara-3.18.0/lib/capybara.rb:315:in `reset_sessions!'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/capybara-3.18.0/lib/capybara/rspec.rb:18:in `block (2 levels) in <top (required)>'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec/retry.rb:123:in `block in run'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec/retry.rb:110:in `loop'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec/retry.rb:110:in `run'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec_ext/rspec_ext.rb:12:in `run_with_retry'
# ./spec/spec_helper.rb:31:in `block (2 levels) in <top (required)>'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec/retry.rb:123:in `block in run'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec/retry.rb:110:in `loop'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec/retry.rb:110:in `run'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec_ext/rspec_ext.rb:12:in `run_with_retry'
# /Users/my_user/.rvm/gems/ruby-2.5.5/gems/rspec-retry-0.6.1/lib/rspec/retry.rb:37:in `block (2 levels) in setup'
@twalpole

This comment has been minimized.

Copy link
Member

commented Apr 29, 2019

If it works fine with Chrome 73 but 74 times out that would tend to imply an issue with Chrome of chromedriver. Without a way to replicate the issue I can't even really attempt to diagnose anything. Capybaras test suite runs against Chrome 74 without issue - https://travis-ci.org/teamcapybara/capybara/jobs/525827115 . If someone can provide a way to replicate I can look further ...

@bgwilson87

This comment has been minimized.

Copy link

commented Apr 29, 2019

This is the config that I'm using, if that helps:

require 'selenium/webdriver'

Capybara.default_max_wait_time = 5

Capybara.register_driver :chrome do |app|
  Capybara::Selenium::Driver.new(app, browser: :chrome)
end

Capybara.register_driver :headless_chrome do |app|
  capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
    chromeOptions: { args: %w(headless disable-gpu window-size=1280,2000 no-sandbox) }
  )

  Capybara::Selenium::Driver.new app,
    browser: :chrome,
    desired_capabilities: capabilities
end

Capybara.javascript_driver = :headless_chrome

I have noticed that when I remove headless from chromeOptions, it works. It very well may be a chrome / chromedriver issue.

@iwz

This comment has been minimized.

Copy link

commented Apr 29, 2019

Here's another sample config:

require 'webdrivers'
require 'selenium-webdriver'

Capybara.register_driver :chrome do |app|
  Capybara::Selenium::Driver.new(app, browser: :chrome)
end

Capybara.register_driver :headless_chrome do |app|
  capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
    chromeOptions: { args: %w(headless window-size=1024,768) },
    loggingPrefs: { browser: 'ALL' }
  )

  Capybara::Selenium::Driver.new app,
    browser: :chrome,
    desired_capabilities: capabilities
end

Capybara.default_max_wait_time = 5
Capybara.javascript_driver = :headless_chrome # :chrome simulates behavior in browser
Capybara.server_port = 31337 + ENV['TEST_ENV_NUMBER'].to_i
Capybara.configure do |config|
  config.always_include_port = true
end

And the basic test case is (with Chrome 74, and webdrivers):

require "spec_helper.rb"

visit "/"
@twalpole

This comment has been minimized.

Copy link
Member

commented Apr 29, 2019

@bgwilson87 @iwz Can you try adding the disable-features=VizDisplayCompositor chrome option and see if that makes any difference

@iwz

This comment has been minimized.

Copy link

commented Apr 29, 2019

@bgwilson87 @iwz Can you try adding the disable-features=VizDisplayCompositor chrome option and see if that makes any difference

@twalpole this does not make a difference for me.

@twalpole

This comment has been minimized.

Copy link
Member

commented Apr 29, 2019

@iwz Ok then I think it's a chromedriver issue where there's nothing Capybara can really do about it. It doesn't affect the Capybara tests on travis or locally for me on MacOS 10.14.4 so it's possible it's a platform specific issue in chromedriver. Does it occur in the same code location for you? (in session reset when Capybara is asking chromedriver for a list of the open windows) If so, you're not doing something like closing all the open windows inside a test that could cause chromedriver to hit an edge case??

@bgwilson87

This comment has been minimized.

Copy link

commented Apr 30, 2019

I have opened an issue in chromedriver here https://bugs.chromium.org/p/chromedriver/issues/detail?id=2885

@ArthurGIT2017

This comment has been minimized.

Copy link

commented Apr 30, 2019

The following Ruby code didn't reproduce this issue:

Selenium::WebDriver::Chrome.driver_path = File.join("<path_to_v74_chromedriver>/chromedriver")
options = Selenium::WebDriver::Chrome::Options.new(:binary=>"<path_to_v74_chrome>/chrome")
options.add_argument('--headless')
driver=Selenium::WebDriver.for :chrome, options: options
driver.get 'http://google.com/'

@iwz

This comment has been minimized.

Copy link

commented May 1, 2019

Update I've since replaced the following workaround with ar31an's fix.

There is a workaround: disable --headless. With headless turned off, the Capybara and chromedriver work fine with Chrome 74.

@RaipheKelsch

This comment has been minimized.

Copy link

commented May 1, 2019

We are also experiencing this issue with all versions 3.16 and above let me know if you need further information.

@twalpole

This comment has been minimized.

Copy link
Member

commented May 1, 2019

@RaipheKelsch The further information we need is a self contained way to reproduce this issue. As stated above the Capybara test suite runs fine against Chrome/chromedriver 74 on TravisCI (in both headless and headed configurations).

Since you've mentioned Capybara 3.16. It made a change over to using a persistent connection which could theoretically cause issues if you are running against remote connections that prevent persistent connections for some reason, however I believe that would be a different issue than the one being discussed here and in that environment would probably affect more than just chromedriver 74.

@CasJam

This comment has been minimized.

Copy link

commented May 3, 2019

it seems the Chrome 74 upgrade broke my tests as well. I'm seeing this error:

Selenium::WebDriver::Error::SessionNotCreatedError:
        session not created: Chrome version must be between 70 and 73
          (Driver info: chromedriver=73.0.3683.20 (8e2b610813e167eee3619ac4ce6e42e3ec622017),platform=Mac OS X 10.13.6 x86_64)

Chrome auto-updated to Version 74.0.3729.131

I tried downgrading to v72 using the link from @iwz's post above, installed it, my tests passed, but I was unable to launch Chrome on my mac with that version (it showed some error telling me "Chrome is damaged, move it to trash".

So now I'm back to running the latest Chrome version, and all my JS tests fail...

Waiting for someone to provide instructions on what to do!

@twalpole

This comment has been minimized.

Copy link
Member

commented May 3, 2019

@CasJam The chromedriver version you’re using needs to match the chrome version . If you’re using Chrome 74.x you need chromedriver 74.x to go with it

@greena13

This comment has been minimized.

Copy link

commented May 3, 2019

Update: I've since replaced the following workaround with the ar31an's fix.

Original:

I've found a work-around that is sufficient for my needs; it may help others:

# @TODO Remove this Monkey Patch after issue is resolved with running Chrome 74 in
#       headless mode: https://github.com/teamcapybara/capybara/issues/2181
module Selenium
  module WebDriver
    class Options
      # capybara/rspec installs a RSpec callback that runs after each test and resets
      # the session - part of which is deleting all cookies. However the call to Chrome
      # Webdriver to delete all cookies in Chrome 74 hangs when run in headless mode 
      # (the reasons for which are still unknown).
      #
      # Fortunately, the call to set a cookie is still functioning and we can rely
      # on expired cookies being cleared by Chrome, so we iterate over all current
      # cookies and set their expiry date to some time in the past - effectively
      # deleting them.
      def delete_all_cookies
        all_cookies.each do |cookie|
          add_cookie(name: cookie[:name], value: '', expires: Time.now - 1.second)
        end
      end
    end
  end
end

The issue appears to happen whenever a page has some sort of external dependency (an asynchronous script, or an iframe with content from another domain, for example). I am not sure, but suspect it may be whenever an cookie for an external domain is set.

I am, however, reasonably sure this is in fact an issue with Chrome or Chrome Driver, and not Capybara.

If anyone wishes to debug the underlying cause or develop a better workaround the one above, you can configure the chrome driver to log out to file, like so:

Capybara.register_driver :headless_chrome do |app|
  capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
    chromeOptions: { args: %w(headless disable-gpu) }
  )

  Capybara::Selenium::Driver.new app,
                                 browser: :chrome,
                                 desired_capabilities: capabilities,
                                 driver_opts: {
                                   verbose: true,
                                   log_path: 'path/to/app/tmp/chromedriver.log'
                                 }
end
@greena13

This comment has been minimized.

Copy link

commented May 3, 2019

@CasJam, you may also find it useful to temporarily enable the webdriver gem's logging to confirm what version of the Chrome webdriver you are using (it will log as much to the console the next time you run your test suite):

Webdrivers.logger.level = :DEBUG
@CasJam

This comment has been minimized.

Copy link

commented May 3, 2019

thanks @twalpole @greena13 I updated chromedriver to 74.0.3729.6 and tests are working again.

@pixiitech

This comment has been minimized.

Copy link

commented May 3, 2019

@greena13 I'm trying to implement your patch, but I don't know where to put this file... I tried config/initializers/selenium.rb but this did not work.

@greena13

This comment has been minimized.

Copy link

commented May 4, 2019

@pixiitech, I put it in a file in the /spec/support/ directory and then required that file in /spec/spec_helper.rb.

I don't have the code in front of me at the moment, but you may need to play around with the order that you require it relative to where you require capybara.

@jackcasey

This comment has been minimized.

Copy link

commented May 7, 2019

@greena13 Thanks for that patch! I was about to eat my keyboard. It works for me.

@twalpole

This comment has been minimized.

Copy link
Member

commented May 7, 2019

@greena13 Are you running against a remote instance of Chrome, or a local one? With a local chrome instance and a relatively current version of selenium-webdriver the workaround you posted should never actually be called.

@jeppeliisberg

This comment has been minimized.

Copy link

commented May 8, 2019

@greena13 your patch didn't work for me unfortunately :-( I'm still stuck with timeouts in my local development.

However, tests run fine on Heroku CI using https://github.com/heroku/heroku-buildpack-google-chrome and https://github.com/heroku/heroku-buildpack-chromedriver which in turn download the latest chrome and chromdriver (logs says -----> Downloading chromedriver v74.0.3729.6...).

I'm looking into it further as time allows and will post any findings here...

@jeppeliisberg

This comment has been minimized.

Copy link

commented May 8, 2019

Quick update - after having tried with chrome beta (v75) I reinstalled stable (v74), downloaded chromedriver v74.0.3729.6 and moved it to /usr/local/bin/ and now my test suite runs again WITHOUT the patch from @greena13.

I can't explain what happened though.

My configuration:

chrome_bin = ENV.fetch("GOOGLE_CHROME_SHIM", nil)
chrome_opts = chrome_bin ? { "chromeOptions" => { "binary" => chrome_bin } } : { "chromeOptions" => { "args" => %w[headless no-sandbox] } }

Capybara.register_driver :chrome do |app|
  Capybara::Selenium::Driver.new(
    app,
    browser: :chrome,
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(chrome_opts)
  )
end
Capybara.javascript_driver = :chrome

The GOOGLE_CHROME_SHIM is for Heroku CI (see earlier post).

@HarlemSquirrel

This comment has been minimized.

Copy link

commented May 8, 2019

I solved this on CircleCI by pinning my container to the last hash that worked and using chromedriver-helper to install chromedriver 73.

version: 2
jobs:
  build:
    docker:
    - image: circleci/jruby@sha256:66e1c96d6836cd0c2edbd81570f370e798e0d770a84a3d42df38967709eb9082
      environment:
        JRUBY_OPTS: --dev -Xcompile.invokedynamic=true -J-XX:+UseCodeCacheFlushing
          -J-Xmx1g
        RAILS_ENV: test
        RACK_ENV: test
    working_directory: ~/repo
    steps:
    - checkout
    - restore_cache:
        keys:
        - v1-dependencies-{{ checksum "Gemfile.lock" }}
        - v1-dependencies-
    - run:
        name: install dependencies
        command: |
          sudo apt install make gcc g++
          bundle install --jobs=4 --retry=3 --path vendor/bundle \
            --without development doc production
    - save_cache:
        paths:
        - ./vendor/bundle
        key: v1-dependencies-{{ checksum "Gemfile.lock" }}
    - run:
        name: run tests
        command: |
          google-chrome --version
          bundle exec chromedriver-update 73.0.3683.68
          bundle exec chromedriver-helper --version

          mkdir /tmp/test-results
          TEST_FILES="$(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings)"

          bundle exec rspec --format progress \
                          --format RspecJunitFormatter \
                          --out /tmp/test-results/rspec.xml \
                          $TEST_FILES
@ar31an

This comment has been minimized.

Copy link

commented May 8, 2019

I have had the same issue with capybara specs on mac. Adding this argument solved the issue:

--enable-features=NetworkService,NetworkServiceInProcess

Reference: https://bugs.chromium.org/p/chromedriver/issues/detail?id=2897#c4

My configuration:

  capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
    chromeOptions: {
      args: %w[
        headless disable-gpu no-sandbox
        --window-size=1980,1080 --enable-features=NetworkService,NetworkServiceInProcess
      ]
    }
  )

  Capybara::Selenium::Driver.new app, browser: :chrome, desired_capabilities: capabilities```
@nruth

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

Update: See ar31an's post above instead, unless you want to avoid auto-updates in future, it fixes the problem instead of avoiding it.

--

I've been getting weird test failures since Chrome 74 installed itself (initially the Net::ReadTimeout, then after moving to webdrivers it just broke content based browser synchronisation or introduced some session cleanup race condition vs running without headless) and would like to suggest another work-around for people who don't have a Docker/VM testing setup. It unfortunately does nothing to help find or fix the problem, but might save someone else some time.

Chromium: A Downgrading Solution

Old Chrome versions aren't officially made available, and getting it from a third party is dangerous. We've got another option though: Chromium, which does make old builds available. And they don't auto-update.

I've used this approach on my Mac to get my tests running locally again without having to remove the headless flag. This is suitable for folk who want their tests to run and don't care which browser/version they run in, but don't want to spend time re-stabilising their tests in headless Firefox. This assumes use of the webdrivers gem. I've not tried it with chromedriver-helper.

  1. Download a Chromium build corresponding with Chrome 73, as per https://www.chromium.org/getting-involved/download-chromium – I went with https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/625897/
  2. Unzip the Chromium download & move the app file bundle to your home directory, or project directory, or wherever you are comfortable with
  3. Reconfigure webdrivers chrome path to point at this version of chrome
  4. Run tests

My specific setup code is this before registering my capybara drivers:

if (chrome_path = ENV["WEBDRIVER_CHROME_PATH"])
  Selenium::WebDriver::Chrome.path = chrome_path
end

And a dotenv file .env.test.local to set the path:

WEBDRIVER_CHROME_PATH=/Volumes/dev/bin/Chromium.app/Contents/MacOS/Chromium

webdrivers correctly and automatically switched my chromedriver version from 74 to 73 when I ran the tests, without me needing to do anything special. Afterwards ~/.webdrivers/chromedriver -v comes out like ChromeDriver 73.0.3683.68, and more importantly the tests passed.

I like this .env approach because switching back to Chrome is as simple as removing that line from the dotenv file, which is gitignored and will only affect my installation. No need to commit/share anything. It does mean each developer will need to do it independently though so YMMV.

Security Disclaimer: using an old unofficial browser build is introducing a security flaw in your system. Consider firewalling/sandboxing it if you can. In my case I'm restricting its network access to where I expect my tests to go with LittleSnitch.

@maxshelley

This comment has been minimized.

Copy link

commented May 10, 2019

For those using Heroku, I just wanted to combine what @ar31an and @jeppeliisberg mention above in case you need another example. Adding the additional argument to the code that Heroku provide in their Google Chrome buildpack documentation resolved my issue locally without needing to install Chrome Beta and it continued to work on Heroku .

Here's the configuration that worked for me:

require "selenium/webdriver"

chrome_bin = ENV.fetch('GOOGLE_CHROME_SHIM', nil)

chrome_opts = chrome_bin ? { "chromeOptions" => { "binary" => chrome_bin } } : { chromeOptions: { args: ['headless', 'disable-gpu', '--enable-features=NetworkService,NetworkServiceInProcess'] } }

Capybara.register_driver :chrome do |app|
  Capybara::Selenium::Driver.new(
     app,
     browser: :chrome,
     desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome(chrome_opts)
  )
end

Capybara.javascript_driver = :chrome

Hope that helps someone!

@twalpole

This comment has been minimized.

Copy link
Member

commented May 13, 2019

Since I haven't been able to reproduce this issue in any of my environments, has anyone that experienced this issue with Chrome 74 tried Chrome 75? If so is the issue solved on 75 without needing the NetworkService and NetworkServiceInProcess options?

@Confusion

This comment has been minimized.

Copy link

commented May 16, 2019

I've been experiencing this issue since about two weeks, but with chromium and chromedriver 73, in both headless and non-headless mode (where the chromium and chromedriver run in a Docker container). Locally I observe many sockets (running in the thousands after a while) in TIME_WAIT, reminiscent of earlier problems with correctly closing connections or lack of keepalive.

Started happening after upgrade of capybara and selenium-webdriver from Capybara 3.12.0 and selenium-webdriver 3.11.0 to Capybara 3.18.0 and selenium-webdriver 3.142.0. But that may be circumstantial, because that was part of a major upgrade of all gems. And of course chrome also keeps evolving.

Edit: I can reproduce the issue with Capybara 3.12.0 and selenium-webdriver 3.11.0, so those upgrades aren't the issue.

@twalpole

This comment has been minimized.

Copy link
Member

commented May 17, 2019

@Confusion If you're using Chrome/chromedriver 73 it's a different issue than this thread is talking about (which is for 74). Since you're running in a container it's probable you need to specify a combination of chrome options such as --no-sandbox, --disable-dev-shm-usage and --disable-features=VizDisplayCompositor.

@catmando

This comment has been minimized.

Copy link

commented May 18, 2019

@ar31an 's solution worked (adding --enable-features=NetworkService,NetworkServiceInProcess to the options), and I also found this issue chromedriver issue https://groups.google.com/forum/#!msg/chromedriver-users/ktp-s_0M5NM/9VQO3CKFAAAJ suggesting the same work around.

@twalpole

This comment has been minimized.

Copy link
Member

commented May 20, 2019

Closing this since it is a chrome/chromedriver issue, with an available fix, and not a Capybara issue

@ndbroadbent

This comment has been minimized.

Copy link

commented Jun 16, 2019

I was struggling with Net::ReadTimeout errors after upgrading to Google Chrome and chromedriver 75.0.3770.90.

I tried all of the options that were mentioned, but these didn't help:

options.add_argument('--enable-features=NetworkService,NetworkServiceInProcess')
options.add_argument('--disable-features=VizDisplayCompositor')
options.add_argument('--disable-dev-shm-usage')

Was still getting Net::ReadTimeout errors with these.

(It did work if I ran as the root user in my Docker container, or if I used the --no-sandbox flag. But those aren't good solutions.)

The solution was to upgrade from capybara 3.22.0 to 3.24.0. (That was the only change I needed to make.) Hope that helps someone else!

@twalpole

This comment has been minimized.

Copy link
Member

commented Jun 16, 2019

@ndbroadbent I'm glad to hear things are working for you, but there really is nothing between 3.22 and 3.24 - 3.22.0...3.24.0 - that should have any affect on network timeouts. Are you 100% sure no other gem / chrome / chromedriver updates occurred??

@ndbroadbent

This comment has been minimized.

Copy link

commented Jun 16, 2019

@twalpole You're right, I downgraded capybara to 3.22.0, and ran the tests in the same Docker container, and they were still passing with no Net::ReadTimeout errors. Then I restarted the Docker container, and the tests were still passing.

That's very weird, because the tests did start passing immediately after I ran bundle update capybara. capybara was the only changed gem in my Gemfile.lock, and I didn't change anything else. I had also reverted all the changes to my capybara config. Chrome and chromedriver are still on 75.0.3770.90.

So I think this is probably just a weird Docker issue, and Chrome wasn't able to start properly in the container. So if anyone else runs into that, I guess try restarting Docker first, or rebuild your images.

sue445 added a commit to sue445/apple_system_status that referenced this issue Jun 18, 2019
sue445 added a commit to sue445/apple_system_status that referenced this issue Jun 18, 2019
damianlegawiec added a commit to spark-solutions/spree that referenced this issue Jul 22, 2019

@lock lock bot locked and limited conversation to collaborators Aug 16, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.