Capybara::Poltergeist::TimeoutError

[dlandberg]

I've got an Capybara::Poltergeist::TimeoutError with a simple line of code:

visit '/'

The debug output:

{"name"=>"set_debug", "args"=>[true]}
{"response"=>true}
{"name"=>"render", "args"=>["test.png", false]}
{"response"=>true}
{"name"=>"visit", "args"=>["http://127.0.0.1:54242/"]}
poltergeist [1376968991944] state default -> loading

Timed out waiting for response to {"name":"visit","args":["http://127.0.0.1:54242/"]}. 
It's possible that this happened because something
took a very long time (for example a page load was slow). 
If so, setting the Poltergeist :timeout
 option to a higher value will help (see the docs for details). If increasing the timeout does not help, this is probably a bug in Poltergeist - please report it to the issue tracker. (Capybara::Poltergeist::TimeoutError)

I'm not sure that it's a poltergeist bug. Seems like the following code in the web_socker_server.rb raises the timeout exception:

IO.select([socket], [], [], timeout) or raise Errno::EWOULDBLOCK

My environment: Mac OS Lion 10.7.5 phantomjs-1.9.1 poltergeist-1.3.0

[yaauie]

I can't reproduce :confused:. Have you tried setting a higher timeout? Do you have logging enabled in your app, and if so do you see the request being made? It's possible your app is just taking too long to start up.

[dlandberg]

Yes sure I've tried to set a higher timeout. It didn't help. Also I've tested the same code on the Mountain Lion and it works...

[yaauie]

@dlandberg what versions of Ruby are you working with? Are they the same across your different OS's?

[dlandberg]

@yaauie ruby 2.0.0 and rails 4. Ruby versions are the same.

[dlandberg]

There are several lines from my env.rb file:

require 'capybara/poltergeist'

Capybara.register_driver :poltergeist do |app|
  Capybara::Poltergeist::Driver.new(app, {debug: true})
end
Capybara.javascript_driver = :poltergeist

Nothing special as for me.

[joeyjoejoejr]

running

after { page.driver.reset! }

Seems to fix it for now, but I;m having this same issue and would be curious to know what the root cause is.

[route]

@joeyjoejoejr That must be done by capybara https://github.com/jnicklas/capybara/blob/master/lib/capybara/rspec.rb#L20

[route]

It's hard to debug in a distance and I have no idea how Mac OS Lion could be related... Would someone want me to participate in it?

[joeyjoejoejr]

@route All I know is that it works. I read it in another issue. I'm not saying that it's the right thing to do or that I know why it works but it does.

I don't think it's Lion related, because it's happening on my ubuntu ci server.

[route]

@joeyjoejoejr What was another issue?

[route]

Does it happen when you run this test alone?

[joeyjoejoejr]

https://github.com/jonleighton/poltergeist/issues/116

It doesn't seem to do it alone. From what I can tell the first test usually passes and then the rest timeout. It's like it isn't getting reset properly or there is something else causing issues.

[route]

Could you try to monkey patch capybara and poltergeist adding some debug to reset! method, then comment your after hook and see if those methods are invoked properly?

[route]

Thanks for linked issue I'll try to find out what changes were made at that moment.

[joeyjoejoejr]

There is something strange going on. The driver.reset! was getting called for every test, but when I actually let it get called is when it starts to timeout. I'm unsure why calling it explicitly changes anything, but overriding it also solves the problem.

[dlandberg]

I can confirm that after { page.driver.reset! } solves this problem

[route]

Very strange.. Let's play with sleep then... Could you add sleep 2 for example to driver.reset! and remove your hook again?

[wkrsz]

"It doesn't seem to do it alone. From what I can tell the first test usually passes and then the rest timeout."

Same here.

[wkrsz]

For me page.driver.reset! has no effect, but Capybara.reset_sessions! does seem to make the issue appear very seldom. Smells like timing issue.

[smojtabai]

This is interesting, I am having the same issue but I also do not see it happen on my Max OSX Lion. I ran my tests a couple hundred times and it never appeared. I have a jenkins server running ubuntu that seems to run into this issue on one call (pretty often). That call happens a bunch of times because I have some nested rspec tests.

before(:each) do
        find('li[heading=Creatives]').click
        page.should have_css('.creative-row', :count => 2)
      end

Error:

Capybara::Poltergeist::TimeoutError: Timed out waiting for response to {"name":"find","args":["css",".creative-row"]}. It's possible that this happened because something took a very long time (for example a page load was slow). If so, setting the Poltergeist :timeout option to a higher value will help (see the docs for details). If increasing the timeout does not help, this is probably a bug in Poltergeist - please report it to the issue tracker.

I set my timeout to 2 minutes.

[pbrumm]

do you have transactional fixtures set to true in your spec_helper?

it needs to be config.use_transactional_fixtures = false

as the poltergeist browser runs in a different thread.

[michaelrkn]

I'm running into a similar issue with https://github.com/epicodus/textbook. All my tests pass fine on my dev machine, and I even provisioned a Nitrous.io box and all my tests pass there as well. But I get weird intermittent failures on Travis CI. Here are my last four builds: https://travis-ci.org/epicodus/textbook/builds/14757934, https://travis-ci.org/epicodus/textbook/builds/14758068, https://travis-ci.org/epicodus/textbook/builds/14770897, https://travis-ci.org/epicodus/textbook/builds/14771361. They all are the exact same codebase, with the exception that the last one includes debug: true, but I get different Poltergeist-related errors each time (and a strange undefined method 'map' for nil:NilClass occasionally). I've tried raising Capybara.default_wait_time = 5 to no avail.

[michaelrkn]

Update: I just added after { page.driver.reset! } and my tests now pass: https://travis-ci.org/epicodus/textbook/builds/14773101.

Update to update: Never mind. It was just a random variation - I re-ran the tests, and I got failures again (https://travis-ci.org/epicodus/textbook/builds/14775755).

[michaelrkn]

Travis support kindly setup a VM for me to debug with. I've tried adding after { page.driver.reset! }, after { Capybara.reset_sessions! }, and after { sleep 2 }, all to no avail. I've tried specifying RSpec's seed to de-randomize the order the tests are run in, and which tests fail still changes on each run. I've tried running a single test over and over; sometimes it passes, sometimes it fails.

Perhaps the most interesting thing I found was that when I tried to grab a screenshot, I got a timeout:

 Failure/Error: save_screenshot('/tmp/new_section.png')
 Capybara::Poltergeist::TimeoutError:
   Timed out waiting for response to {"name":"render","args":["/tmp/new_section.png",false,null]}. It's possible that this happened because something took a very long time (for example a page load was slow). If so, setting the Poltergeist :timeout option to a higher value will help (see the docs for details). If increasing the timeout does not help, this is probably a bug in Poltergeist - please report it to the issue tracker.
 # ./spec/features/sections_pages_spec.rb:11:in `block (2 levels) in <top (required)>'

The other thing that sticks out for me is that I sporadically get undefined method 'map' for nil:NilClass. The line the backtrace refers to is:

fill_in 'Email', with: author.email

I'm at a bit of a loss for how to continue debugging this. For the moment, I'm just going to stop using Travis, since everything reliably passes on my local machine, and my app works properly in production. I'm happy to help try to track down this problem further if it seems like it could be a Poltergeist bug.

[alexmchale]

I'm just throwing myself into the mix here, seeing all of the above issues that everyone is talking about. I've got a Ubuntu VM running locally that gives me the same errors as we're seeing on Travis & Semaphore. I'm hoping having the problem duplicatable locally will help me solve it.

[michaelrkn]

Okay, I got it figured. I have a bit of JavaScript for Usabilla (a feedback button) in my layout, and when I wrapped it in <% if Rails.env != 'test' %>, the problems went away (https://github.com/epicodus/textbook/commit/5941432552713321fd1323d9ccce661b39a8da7e). Any idea why this would cause problems?

[wkrsz]

@michaelrkn Hate to be the party-pooper but I dare say it doesn't cause the problem. Additional scripts affect page load time and thus can affect frequency with which an unrelated timing issue appears.

[Dakuan]

@michaelrkn did you get to the bottom of this at all?

[michaelrkn]

Nothing beyond what I posted above - you can see the commit that fixed it here.

[Senjai]

We have this issue as well. Can't reproduce locally, but our continuous integration servers run into this problem and builds have to be retriggered a few times to succeed.

[DaniG2k]

I am also getting this issue (on Mavericks) when trying to take screenshots: Timed out waiting for response to {"name":"visit","args": ...}

[mrbegood]

Have same problem because of problems with loading assets in my test environment. Fixed by adding into config/environments/test.rb config.assets.debug = true

[lsimoneau]

Also having this issue. For what it's worth, none of the solutions here worked reliably. I have another Rails 4 app with a nearly identical setup and it works fine, the only difference I can think of is that this one has turbolinks on. Are you guys all using turbolinks?

[DaniG2k]

I've disabled turbolinks. Same issue.

On Thu, Feb 27, 2014 at 11:28 AM, Louis Simoneau notifications@github.comwrote:

Also having this issue. For what it's worth, none of the solutions here worked reliably. I have another Rails 4 app with a nearly identical setup and it works fine, the only difference I can think of is that this one has turbolinks on. Are you guys all using turbolinks?

Reply to this email directly or view it on GitHubhttps://github.com/jonleighton/poltergeist/issues/375#issuecomment-36232884 .

[coderberry]

I'm experiencing the same issue.

[amirci]

Me too, same issue

[sobering]

Same issue over here

[JaredSartin]

Adding on to the pile. I have not found any reliable fixes.

[wkrsz]

I haven't seen the issue in months since adding this to my test_helper.rb:

class ActionDispatch::IntegrationTest
  include Capybara::DSL
  self.use_transactional_fixtures = false
  teardown do
    sleep 0.1
    Capybara.reset_sessions!
    sleep 0.1
    page.driver.reset!
    sleep 0.1
  end
end

Commenting out any of above lines makes the error appear again.

[paulzacz]

I'm getting similar issues here. Running Linux Mint 16, ruby2.1.1p76, phantomJS 1.9.2, poltergeist 1.5.0. I haven't changed the default timeout since most pages load within 10 seconds and the default timeout is 30. It's not consistent about what page this timeout happens, but it will typically happen on a find. I tried catching the exception, running Capybara.reset! in order to try again, but reset timed out as well! Often I'll get a timeout when I'm trying to print page.html after I've encountered this error. Although this doesn't happen every time at the same place, my session opens enough pages that I can get it to appear after ~ 20 page loads.

[JaredSartin]

Are you changing the phantomjs log option in the setup of Poltergeist?

I gave mine a proper file IO and it works.

On Tue, Mar 18, 2014 at 2:49 PM, Paul Zaczkiewicz notifications@github.comwrote:

I'm getting similar issues here. Running Linux Mint 16, ruby2.1.1p76, phantomJS 1.9.2, poltergeist 1.5.0. I haven't changed the default timeout since most pages load within 10 seconds and the default timeout is 30. It's not consistent about what page this timeout happens, but it will typically happen on a find. I tried catching the exception, running Capybara.reset! in order to try again, but reset timed out as well! Often I'll get a timeout when I'm trying to print page.html after I've encountered this error. Although this doesn't happen every time at the same place, my session opens enough pages that I can get it to appear after ~ 20 page loads.

— Reply to this email directly or view it on GitHubhttps://github.com/jonleighton/poltergeist/issues/375#issuecomment-37972662 .

Jared Sartin 269.364.1735 | jared.sart.in | @JaredSartin http://twitter.com/JaredSartin

[paulzacz]

No, I'm logging by writing page.html to a File handle periodically within my test.

[mipearson]

We're reaching crisis levels on this issue - it's not at all helpful that we can't work out why PhantomJS is failing intermittently. Seems to be exacerbated by running multiple specs in parallel (yes, we're using different phantomjs ports for each).

[m-o-e]

We're hitting the same bug. None of the workarounds have helped.

Ruby 2.1.1p76 and Rails 4.

[mlackman]

I updated phantomjs from 1.9.0 to 1.9.7 and I did not have this timeout problem anymore.

[Senjai]

Can more people verify if @mlackman's solution works?

[gkop]

I can replicate this on every phantomjs minor revision compatible with poltergeist 1.5.0 up to and including 1.9.7. My hunch is that this is an issue in phantomjs.

[peteonrails]

I ran in to this issue with a Rails 4 app that we deploy to Heroku.

I'm using RSPEC with:

phantomjs-1.9.2.1 poltergeist-1.5.0

We moved the rails_12factor gem from the :production group to [:test, :production], and the issue was resolved. Seems like file IO may indeed be the culprit.

I'm not going to dig too much more right now, but I thought the info might be helpful to the main principals doing the debugging. Happy to answer questions and try stuff.

[larslevie]

A big downside to this workaround is that it dumps log data into the test output. It totally blows up my CI server interface. :frowning:

[pboling]

I am having this issue on:

• Mac OS X 10.9.2
• ruby 2.0.0-p451(installed via rvm)
• rails 3.2.17
• PhanomJS 1.9.7 (installed via brew) using either
• poltergeist @1f0c78572462 (from github)

or

• poltergeist 1.5.0 (from rubygems.org)

Sometimes errors look like this

  3) place first time comped order places the comped order
     Failure/Error: sign_in
     Capybara::Poltergeist::TimeoutError:
       Timed out waiting for response to {"name":"visit","args":["http://outfitter.archer.dev:7171"]}. It's possible that this happened because something took a very long time (for example a page load was slow). If so, setting the Poltergeist :timeout option to a higher value will help (see the docs for details). If increasing the timeout does not help, this is probably a bug in Poltergeist - please report it to the issue tracker.
     # ./spec/support/outfitter_helper.rb:4:in `sign_in'
     # ./spec/features/outfitter/place_comped_order_spec.rb:8:in `block (2 levels) in <top (required)>'
     # ./spec/spec_config/database_cleaner.rb:70:in `block (2 levels) in <top (required)>'

Sometimes they look like this:

  1) place first time comped order places the comped order
     Failure/Error: add_to_cart_and_checkout(product.variants.first.id)
     Capybara::Poltergeist::StatusFailError:
       Request failed to reach server, check DNS and/or server status
     # ./spec/support/outfitter_helper.rb:90:in `add_to_cart_and_checkout'
     # ./spec/features/outfitter/place_comped_order_spec.rb:14:in `block (2 levels) in <top (required)>'
     # ./spec/spec_config/database_cleaner.rb:70:in `block (2 levels) in <top (required)>'

As others noted, of the "features" specs, the first test or two always pass, and all the ones that follow fail.