Capybara::Poltergeist::TimeoutError #375

Closed
dlandberg opened this Issue Aug 20, 2013 · 118 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@yaauie

yaauie Aug 21, 2013

Member

I can't reproduce 😕. 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.

Member

yaauie commented Aug 21, 2013

I can't reproduce 😕. 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

This comment has been minimized.

Show comment
Hide comment
@dlandberg

dlandberg Aug 22, 2013

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...

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

This comment has been minimized.

Show comment
Hide comment
@yaauie

yaauie Aug 22, 2013

Member

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

Member

yaauie commented Aug 22, 2013

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

@dlandberg

This comment has been minimized.

Show comment
Hide comment
@dlandberg

dlandberg Aug 22, 2013

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

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

@dlandberg

This comment has been minimized.

Show comment
Hide comment
@dlandberg

dlandberg Aug 22, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@joeyjoejoejr

joeyjoejoejr Sep 5, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@route

This comment has been minimized.

Show comment
Hide comment
@route

route Sep 5, 2013

Member

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?

Member

route commented Sep 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@joeyjoejoejr

joeyjoejoejr Sep 5, 2013

@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 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

This comment has been minimized.

Show comment
Hide comment
@route

route Sep 5, 2013

Member

@joeyjoejoejr What was another issue?

Member

route commented Sep 5, 2013

@joeyjoejoejr What was another issue?

@route

This comment has been minimized.

Show comment
Hide comment
@route

route Sep 5, 2013

Member

Does it happen when you run this test alone?

Member

route commented Sep 5, 2013

Does it happen when you run this test alone?

@joeyjoejoejr

This comment has been minimized.

Show comment
Hide comment
@joeyjoejoejr

joeyjoejoejr Sep 5, 2013

#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.

#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

This comment has been minimized.

Show comment
Hide comment
@route

route Sep 5, 2013

Member

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?

Member

route commented Sep 5, 2013

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

This comment has been minimized.

Show comment
Hide comment
@route

route Sep 5, 2013

Member

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

Member

route commented Sep 5, 2013

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

@joeyjoejoejr

This comment has been minimized.

Show comment
Hide comment
@joeyjoejoejr

joeyjoejoejr Sep 5, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@dlandberg

dlandberg Sep 5, 2013

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

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

@route

This comment has been minimized.

Show comment
Hide comment
@route

route Sep 6, 2013

Member

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

Member

route commented Sep 6, 2013

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

@WojtekKruszewski

This comment has been minimized.

Show comment
Hide comment
@WojtekKruszewski

WojtekKruszewski Sep 7, 2013

"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.

"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.

@WojtekKruszewski

This comment has been minimized.

Show comment
Hide comment
@WojtekKruszewski

WojtekKruszewski Sep 8, 2013

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.

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 comment has been minimized.

Show comment
Hide comment
@smojtabai

smojtabai Nov 18, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@pbrumm

pbrumm Nov 19, 2013

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.

pbrumm commented Nov 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@michaelrkn

michaelrkn Dec 1, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@michaelrkn

michaelrkn Dec 1, 2013

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).

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

This comment has been minimized.

Show comment
Hide comment
@michaelrkn

michaelrkn Dec 13, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@alexmchale

alexmchale Dec 20, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@michaelrkn

michaelrkn Dec 24, 2013

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 (epicodus/textbook@5941432). Any idea why this would cause problems?

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 (epicodus/textbook@5941432). Any idea why this would cause problems?

@WojtekKruszewski

This comment has been minimized.

Show comment
Hide comment
@WojtekKruszewski

WojtekKruszewski Dec 24, 2013

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@Dakuan

Dakuan Jan 20, 2014

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

Dakuan commented Jan 20, 2014

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

@michaelrkn

This comment has been minimized.

Show comment
Hide comment
@michaelrkn

michaelrkn Jan 20, 2014

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

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

@Senjai

This comment has been minimized.

Show comment
Hide comment
@Senjai

Senjai Feb 12, 2014

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.

Senjai commented Feb 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DaniG2k

DaniG2k Feb 13, 2014

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

DaniG2k commented Feb 13, 2014

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

@mrbegood

This comment has been minimized.

Show comment
Hide comment
@mrbegood

mrbegood Feb 24, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@lsimoneau

lsimoneau Feb 27, 2014

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?

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

This comment has been minimized.

Show comment
Hide comment
@DaniG2k

DaniG2k Feb 27, 2014

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
.

DaniG2k commented Feb 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@coderberry

coderberry Mar 3, 2014

I'm experiencing the same issue.

I'm experiencing the same issue.

@amirci

This comment has been minimized.

Show comment
Hide comment
@amirci

amirci Mar 4, 2014

Me too, same issue

amirci commented Mar 4, 2014

Me too, same issue

@sobering

This comment has been minimized.

Show comment
Hide comment
@sobering

sobering Mar 4, 2014

Same issue over here

sobering commented Mar 4, 2014

Same issue over here

@JaredSartin

This comment has been minimized.

Show comment
Hide comment
@JaredSartin

JaredSartin Mar 5, 2014

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

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

@WojtekKruszewski

This comment has been minimized.

Show comment
Hide comment
@WojtekKruszewski

WojtekKruszewski Mar 5, 2014

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.

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.

@MinutemanZ

This comment has been minimized.

Show comment
Hide comment
@MinutemanZ

MinutemanZ Mar 18, 2014

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.

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.

@g-ilham

This comment has been minimized.

Show comment
Hide comment
@g-ilham

g-ilham Oct 20, 2014

i'm using in Gemfile.lock:

mime-types (2.4.2)
capybara (2.2.1)
poltergeist (1.5.1)
websocket-driver (0.3.5)

I added a check to the test environment for some plug-in in my views:

 - unless Rails.env.test?

i also added:

 after { Capybara.reset_sessions! }

All this helped to solve the problem
Inclined to think that the main reason is the js plugins. Not required plug-ins in a test environment to exclude!
Also, try to divide the tests. Poltergeist is often no time to load the entire environment because of this there are knitted errors. I got rid of it by adding a sleep (1).

g-ilham commented Oct 20, 2014

i'm using in Gemfile.lock:

mime-types (2.4.2)
capybara (2.2.1)
poltergeist (1.5.1)
websocket-driver (0.3.5)

I added a check to the test environment for some plug-in in my views:

 - unless Rails.env.test?

i also added:

 after { Capybara.reset_sessions! }

All this helped to solve the problem
Inclined to think that the main reason is the js plugins. Not required plug-ins in a test environment to exclude!
Also, try to divide the tests. Poltergeist is often no time to load the entire environment because of this there are knitted errors. I got rid of it by adding a sleep (1).

@ZachBeta

This comment has been minimized.

Show comment
Hide comment
@ZachBeta

ZachBeta Oct 20, 2014

We were finding the biggest issue was the size of our assets directory. Since our test suite was compiling assets on request, the first request was often slowed down enough that it would timeout on our leaner build machines but run just fine on our heartier development machines.

We have a number of shell scripts that setup our config files so we added a simple bundle exec rake assets:precompile 2>/dev/null to precompile our assets and pipe the output to dev/null to keep our build logs from getting too noisy.

EDIT: Slightly longer blog post writeup Breaking the Build. Breaking the Build. – Continuity Control Engineering

We were finding the biggest issue was the size of our assets directory. Since our test suite was compiling assets on request, the first request was often slowed down enough that it would timeout on our leaner build machines but run just fine on our heartier development machines.

We have a number of shell scripts that setup our config files so we added a simple bundle exec rake assets:precompile 2>/dev/null to precompile our assets and pipe the output to dev/null to keep our build logs from getting too noisy.

EDIT: Slightly longer blog post writeup Breaking the Build. Breaking the Build. – Continuity Control Engineering

@aprescott

This comment has been minimized.

Show comment
Hide comment
@aprescott

aprescott Oct 20, 2014

Contributor

@ZachBeta I think this should also help avoid that problem:

config.before(:all, type: :feature) do
  visit "/assets/application.css"
  visit "/assets/application.js"
end

It's avoided any problems fairly well where I work.

Contributor

aprescott commented Oct 20, 2014

@ZachBeta I think this should also help avoid that problem:

config.before(:all, type: :feature) do
  visit "/assets/application.css"
  visit "/assets/application.js"
end

It's avoided any problems fairly well where I work.

@adayag

This comment has been minimized.

Show comment
Hide comment
@adayag

adayag Oct 20, 2014

We have been testing our facebook login flow and have been getting consistent failing tests as of last week. There have been no significant changes in our setup since then and running previously green test suites have resulted in the same failing result.

We are using poltergeist 1.5.1

World(Module.new do
  def window_handles
    page.driver.browser.window_handles
  end

  def within_other_window(&block)
    expect(window_handles).to_not be_empty
    sleep 0.5
    page.within_window window_handles.last, &block
  end
end)
email = "charlie_kxmedmp_fergiesky@xxxxx.net"

When /^I log in via facebook.*$/ do
  expect do
    page.find(".facebook-login-button").click
  end.to change { window_handles.length }

  within_other_window do
    fill_in 'email', with: email
    fill_in 'pass', with: 'password'
    click_button 'Log In'
  end
  window_count = window_handles.length
  expect(page).to have_selector "#bar"
end
Timed out waiting for response to {"name":"push_window","args":["f36b411434"]}. 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)
./features/step_definitions/facebook_steps.rb:9:in `within_other_window'
./features/step_definitions/facebook_steps.rb:19:in `/^I log in via facebook.*$/'
./features/support/hooks.rb:25:in `call'
./features/support/hooks.rb:25:in `block in <top (required)>'
features/acquisitions.feature:55:in `When I log in via facebook again'
Capybara.javascript_driver = :poltergeist
Capybara.server_port = 51674
Capybara.default_wait_time = 14
Capybara.register_driver :poltergeist do |app|

  Capybara::Poltergeist::Driver.new(app, timeout: 60, js_errors: true,
                                    phantomjs_logger: Capybara::Poltergeist::FilteringLogger,
                                    phantomjs_options: %w[--load-images=no])
end

We have tried multiple workarounds posted on this thread and others but to no avail. It was previously intermittent within an acceptable failure rate but as we haven't had a green build in a week we are unsure what to do. Any advice would be appreciated.

adayag commented Oct 20, 2014

We have been testing our facebook login flow and have been getting consistent failing tests as of last week. There have been no significant changes in our setup since then and running previously green test suites have resulted in the same failing result.

We are using poltergeist 1.5.1

World(Module.new do
  def window_handles
    page.driver.browser.window_handles
  end

  def within_other_window(&block)
    expect(window_handles).to_not be_empty
    sleep 0.5
    page.within_window window_handles.last, &block
  end
end)
email = "charlie_kxmedmp_fergiesky@xxxxx.net"

When /^I log in via facebook.*$/ do
  expect do
    page.find(".facebook-login-button").click
  end.to change { window_handles.length }

  within_other_window do
    fill_in 'email', with: email
    fill_in 'pass', with: 'password'
    click_button 'Log In'
  end
  window_count = window_handles.length
  expect(page).to have_selector "#bar"
end
Timed out waiting for response to {"name":"push_window","args":["f36b411434"]}. 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)
./features/step_definitions/facebook_steps.rb:9:in `within_other_window'
./features/step_definitions/facebook_steps.rb:19:in `/^I log in via facebook.*$/'
./features/support/hooks.rb:25:in `call'
./features/support/hooks.rb:25:in `block in <top (required)>'
features/acquisitions.feature:55:in `When I log in via facebook again'
Capybara.javascript_driver = :poltergeist
Capybara.server_port = 51674
Capybara.default_wait_time = 14
Capybara.register_driver :poltergeist do |app|

  Capybara::Poltergeist::Driver.new(app, timeout: 60, js_errors: true,
                                    phantomjs_logger: Capybara::Poltergeist::FilteringLogger,
                                    phantomjs_options: %w[--load-images=no])
end

We have tried multiple workarounds posted on this thread and others but to no avail. It was previously intermittent within an acceptable failure rate but as we haven't had a green build in a week we are unsure what to do. Any advice would be appreciated.

@jmccartie

This comment has been minimized.

Show comment
Hide comment
@jmccartie

jmccartie Nov 6, 2014

@futhr 's solution fixed it for me. Started happening after I switched from Unicorn to Puma

@futhr 's solution fixed it for me. Started happening after I switched from Unicorn to Puma

@agenteo

This comment has been minimized.

Show comment
Hide comment
@agenteo

agenteo Feb 27, 2015

@ZachBeta tried your solution, looked really promising. After 3 days it's back.

My timeout is set to 180.

To @aprescott and whoever posted a solution I'd love to hear for how long this flaky tests disappeared for.

If you run 10/15 builds a day you should wait at least one or two weeks before calling it gone. This is how we're trying to keep track of it http://teotti.com/a-process-to-identify-and-monitor-inconsistently-failing-automated-tests/#document-the-flaky-test

To others seeing this flaky test perhaps https://github.com/dblock/rspec-rerun or https://github.com/y310/rspec-retry might help.

agenteo commented Feb 27, 2015

@ZachBeta tried your solution, looked really promising. After 3 days it's back.

My timeout is set to 180.

To @aprescott and whoever posted a solution I'd love to hear for how long this flaky tests disappeared for.

If you run 10/15 builds a day you should wait at least one or two weeks before calling it gone. This is how we're trying to keep track of it http://teotti.com/a-process-to-identify-and-monitor-inconsistently-failing-automated-tests/#document-the-flaky-test

To others seeing this flaky test perhaps https://github.com/dblock/rspec-rerun or https://github.com/y310/rspec-retry might help.

@claptimes5

This comment has been minimized.

Show comment
Hide comment
@claptimes5

claptimes5 Feb 27, 2015

I've had this issue in the past and was wondering if everyone here has been using database_cleaner? I came across a recent issue where database_cleaner left open transactions in the database. This prevented the deletion or truncation calls from completing. Basically they timed out or hung forever.

DatabaseCleaner/database_cleaner#292
DatabaseCleaner/database_cleaner#273

I made a fork that checks (hacks) if there are any open transactions when deleting/truncating (claptimes5/database_cleaner@347b74b. It's tough, since then poltergeist failures are intermittent, but can someone check and see if this helps?

I've had this issue in the past and was wondering if everyone here has been using database_cleaner? I came across a recent issue where database_cleaner left open transactions in the database. This prevented the deletion or truncation calls from completing. Basically they timed out or hung forever.

DatabaseCleaner/database_cleaner#292
DatabaseCleaner/database_cleaner#273

I made a fork that checks (hacks) if there are any open transactions when deleting/truncating (claptimes5/database_cleaner@347b74b. It's tough, since then poltergeist failures are intermittent, but can someone check and see if this helps?

@shedd

This comment has been minimized.

Show comment
Hide comment
@shedd

shedd Mar 17, 2015

@claptimes5 thanks! interesting theory. we are using DatabaseCleaner and I gave your fork a try. Unfortunately, we still hit the timeout errors. It's possible that this may help, but I was unable to confirm that.

shedd commented Mar 17, 2015

@claptimes5 thanks! interesting theory. we are using DatabaseCleaner and I gave your fork a try. Unfortunately, we still hit the timeout errors. It's possible that this may help, but I was unable to confirm that.

@claptimes5

This comment has been minimized.

Show comment
Hide comment
@claptimes5

claptimes5 Mar 17, 2015

@shedd What database are you using? I had to stop/start my instance to reset the sessions.

@shedd What database are you using? I had to stop/start my instance to reset the sessions.

@shedd

This comment has been minimized.

Show comment
Hide comment
@shedd

shedd Mar 17, 2015

Postgres. We reproduced the timeouts on our CI service, so it's a fresh instance/container on each test run.

shedd commented Mar 17, 2015

Postgres. We reproduced the timeouts on our CI service, so it's a fresh instance/container on each test run.

@Petercopter

This comment has been minimized.

Show comment
Hide comment
@Petercopter

Petercopter Mar 31, 2015

👍 Using Postgres, database_cleaner, Capybara, Poltergeist, and Rails 4. Timing out. Still debugging. Works on Rails 3.x.

👍 Using Postgres, database_cleaner, Capybara, Poltergeist, and Rails 4. Timing out. Still debugging. Works on Rails 3.x.

@andrewhao

This comment has been minimized.

Show comment
Hide comment
@andrewhao

andrewhao Mar 31, 2015

On our project, none of the above solutions worked until we disabled rack-timeout in test environments: heroku/rack-timeout#55

On our project, none of the above solutions worked until we disabled rack-timeout in test environments: heroku/rack-timeout#55

@showaltb

This comment has been minimized.

Show comment
Hide comment
@showaltb

showaltb Apr 2, 2015

The problem for me is related to Ajax. Capybara makes a call to driver.reset! after every scenario. If an Ajax call is still running, I get the timeout error, with all subsequent tests failing.

If I wait for Ajax (wait for page.evaluate_script('$.active > 0') to become false), everything is good.

showaltb commented Apr 2, 2015

The problem for me is related to Ajax. Capybara makes a call to driver.reset! after every scenario. If an Ajax call is still running, I get the timeout error, with all subsequent tests failing.

If I wait for Ajax (wait for page.evaluate_script('$.active > 0') to become false), everything is good.

@shedd

This comment has been minimized.

Show comment
Hide comment
@shedd

shedd Apr 3, 2015

On our project, none of the above solutions worked until we disabled rack-timeout in test environments: heroku/rack-timeout#55

Thanks @andrewhao - disabling rack-timeout was actually a big help for us!

shedd commented Apr 3, 2015

On our project, none of the above solutions worked until we disabled rack-timeout in test environments: heroku/rack-timeout#55

Thanks @andrewhao - disabling rack-timeout was actually a big help for us!

pgwillia added a commit to ualbertalib/HydraNorth that referenced this issue Apr 13, 2015

pgwillia added a commit to ualbertalib/HydraNorth that referenced this issue Apr 13, 2015

pgwillia added a commit to ualbertalib/HydraNorth that referenced this issue Apr 13, 2015

@pmorton

This comment has been minimized.

Show comment
Hide comment
@pmorton

pmorton Apr 28, 2015

Hi all. In our environment I found that the timeout was caused as a result of a lot of assets being rendered. From OSX I was able to use opensnoop (a dtrace tool) to see what files were being opened. Every time poltergeist would timeout, it was a result of the ruby process trying to compile assets. I achieved test stability by pre-compiling assets for test and setting config.assets.digest = true.

pmorton commented Apr 28, 2015

Hi all. In our environment I found that the timeout was caused as a result of a lot of assets being rendered. From OSX I was able to use opensnoop (a dtrace tool) to see what files were being opened. Every time poltergeist would timeout, it was a result of the ruby process trying to compile assets. I achieved test stability by pre-compiling assets for test and setting config.assets.digest = true.

@glennfu

This comment has been minimized.

Show comment
Hide comment
@glennfu

glennfu May 1, 2015

I eventually had to abandon Poltergeist because of this error. I was using it to load external urls in a rake task to test if page was loading properly. The task would run once a minute opening up a cloudfront cdn cached page. Sometimes I would get the timeout error, most of the time I wouldn't. So there were no testing frameworks in the way or asset compilation issues to tinker with.

glennfu commented May 1, 2015

I eventually had to abandon Poltergeist because of this error. I was using it to load external urls in a rake task to test if page was loading properly. The task would run once a minute opening up a cloudfront cdn cached page. Sometimes I would get the timeout error, most of the time I wouldn't. So there were no testing frameworks in the way or asset compilation issues to tinker with.

@mscottford

This comment has been minimized.

Show comment
Hide comment
@mscottford

mscottford May 1, 2015

@glennfu: Sounds like your script would be a nice small example of this issue. Are you able to post a gist?

@glennfu: Sounds like your script would be a nice small example of this issue. Are you able to post a gist?

@glennfu

This comment has been minimized.

Show comment
Hide comment
@glennfu

glennfu May 1, 2015

Here's the trimmed down version:

require 'capybara'
require 'capybara/dsl'
require 'capybara/poltergeist'

Capybara.run_server = false
Capybara.app_host = "http://america.aljazeera.com"

session = Capybara::Session.new(:poltergeist, nil)
session.visit "/"

success = !!(session.body =~ /Al Jazeera America/)

The kicker is that this was run once a minute on a clock thread and might not fail for hours. When it would fail, none of the other monitoring setups would detect any issues, and manually checking the site showed it was still loading just fine.

I removed the poltergeist code in August 2014, so it's been a while and it doesn't look like I wrote down the specific errors I was seeing. I just remember that it wasn't a capturable exception, the app would simply die. That was the biggest problem since I couldn't just rescue and retry.

I hope this is helpful!

glennfu commented May 1, 2015

Here's the trimmed down version:

require 'capybara'
require 'capybara/dsl'
require 'capybara/poltergeist'

Capybara.run_server = false
Capybara.app_host = "http://america.aljazeera.com"

session = Capybara::Session.new(:poltergeist, nil)
session.visit "/"

success = !!(session.body =~ /Al Jazeera America/)

The kicker is that this was run once a minute on a clock thread and might not fail for hours. When it would fail, none of the other monitoring setups would detect any issues, and manually checking the site showed it was still loading just fine.

I removed the poltergeist code in August 2014, so it's been a while and it doesn't look like I wrote down the specific errors I was seeing. I just remember that it wasn't a capturable exception, the app would simply die. That was the biggest problem since I couldn't just rescue and retry.

I hope this is helpful!

@rschooley

This comment has been minimized.

Show comment
Hide comment
@rschooley

rschooley May 7, 2015

For me this started when we added rack-timeout to my project.

After trying everything in this thread I stumbled into:
heroku/rack-timeout#55

Leading me to this sample commit:
craftsmen/roll@04c3d86

Leaving this here incase it helps anyone else getting this issue for the same reason (it could happen for other reasons as well).

For me this started when we added rack-timeout to my project.

After trying everything in this thread I stumbled into:
heroku/rack-timeout#55

Leading me to this sample commit:
craftsmen/roll@04c3d86

Leaving this here incase it helps anyone else getting this issue for the same reason (it could happen for other reasons as well).

@qpowell

This comment has been minimized.

Show comment
Hide comment
@qpowell

qpowell May 18, 2015

@rschooley using rack-timeout in production/staging only solved my issue as well. Thanks!

qpowell commented May 18, 2015

@rschooley using rack-timeout in production/staging only solved my issue as well. Thanks!

@razorcd

This comment has been minimized.

Show comment
Hide comment
@razorcd

razorcd May 23, 2015

I can also confirm that moving rack-timeout gem outside of the test environment fixed the poltergeist/phantomjs timeout issue.

Or setting the timeout to 0 also worked:
Rack::Timeout.timeout = (Rails.env.test? ? 0 : 20)

razorcd commented May 23, 2015

I can also confirm that moving rack-timeout gem outside of the test environment fixed the poltergeist/phantomjs timeout issue.

Or setting the timeout to 0 also worked:
Rack::Timeout.timeout = (Rails.env.test? ? 0 : 20)

@markquezada

This comment has been minimized.

Show comment
Hide comment
@markquezada

markquezada Jun 4, 2015

👍 Moving rack-timeout out of the test group worked for me as well.

BTW, in config/initializers/timeout.rb I simply check if Rack::Timeout is defined before setting:

if defined?(Rack::Timeout)
  Rack::Timeout.timeout = (ENV['RACK_TIMEOUT'] || 20).to_i
end

👍 Moving rack-timeout out of the test group worked for me as well.

BTW, in config/initializers/timeout.rb I simply check if Rack::Timeout is defined before setting:

if defined?(Rack::Timeout)
  Rack::Timeout.timeout = (ENV['RACK_TIMEOUT'] || 20).to_i
end
@sashamd

This comment has been minimized.

Show comment
Hide comment
@sashamd

sashamd Jun 6, 2015

The error can be simulated with

Capybara.default_driver = :poltergeist
Capybara.current_session.driver.headers = {'User-Agent' => 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0'}

sashamd commented Jun 6, 2015

The error can be simulated with

Capybara.default_driver = :poltergeist
Capybara.current_session.driver.headers = {'User-Agent' => 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0'}

@andrewccadman

This comment has been minimized.

Show comment
Hide comment
@andrewccadman

andrewccadman Jun 17, 2015

@showaltb Ajax fix worked for us - thanks a lot - we have had months of problems with this one.
Here is my slightly modified script if it's useful based on this fix and the similar one at
https://robots.thoughtbot.com/automatically-wait-for-ajax-with-capybara

  • we call wait_for_ajax after in both AfterStep and the After hook.

    def wait_for_ajax
    Timeout.timeout(Capybara.default_wait_time) do
    loop until finished_all_ajax_requests?
    end
    end

    def finished_all_ajax_requests?
    begin
    page.evaluate_script("(typeof jQuery !== "undefined") ? jQuery.active : 0").zero?
    rescue Exception => e
    puts e
    end
    end

@showaltb Ajax fix worked for us - thanks a lot - we have had months of problems with this one.
Here is my slightly modified script if it's useful based on this fix and the similar one at
https://robots.thoughtbot.com/automatically-wait-for-ajax-with-capybara

  • we call wait_for_ajax after in both AfterStep and the After hook.

    def wait_for_ajax
    Timeout.timeout(Capybara.default_wait_time) do
    loop until finished_all_ajax_requests?
    end
    end

    def finished_all_ajax_requests?
    begin
    page.evaluate_script("(typeof jQuery !== "undefined") ? jQuery.active : 0").zero?
    rescue Exception => e
    puts e
    end
    end

@jscottbruns

This comment has been minimized.

Show comment
Hide comment
@jscottbruns

jscottbruns Aug 11, 2015

I was able to track this down an external js call taking a very long time and intermittently timing out. In my case the call was to an external service that does some rewriting of the page including some images. If I switch my driver to use webkit and include the option block_unknown_urls my tests run normally.

Capybara.register_driver :webkit do |app|
  Capybara::Webkit::Driver.new(app).tap do |driver|
    driver.block_unknown_urls
  end
end

Since I haven't been able to find a similar option for poltergeist I was able to resolve the issue by including --load-images=no in the phantomjs options. Obviously this will break any tests that depend on loading images but in my case it's not a problem.

Capybara.register_driver :poltergeist do |app|
  options = {
    :window_size  => [1280, 1440],
    :port => 44678+ENV['TEST_ENV_NUMBER'].to_i,
    :phantomjs_options => ['--proxy-type=none', '--load-images=no', '--ignore-ssl-errors=yes', '--ssl-protocol=any'],
    :timeout => 120
  }
  Capybara::Poltergeist::Driver.new(app, options)
end

I was able to track this down an external js call taking a very long time and intermittently timing out. In my case the call was to an external service that does some rewriting of the page including some images. If I switch my driver to use webkit and include the option block_unknown_urls my tests run normally.

Capybara.register_driver :webkit do |app|
  Capybara::Webkit::Driver.new(app).tap do |driver|
    driver.block_unknown_urls
  end
end

Since I haven't been able to find a similar option for poltergeist I was able to resolve the issue by including --load-images=no in the phantomjs options. Obviously this will break any tests that depend on loading images but in my case it's not a problem.

Capybara.register_driver :poltergeist do |app|
  options = {
    :window_size  => [1280, 1440],
    :port => 44678+ENV['TEST_ENV_NUMBER'].to_i,
    :phantomjs_options => ['--proxy-type=none', '--load-images=no', '--ignore-ssl-errors=yes', '--ssl-protocol=any'],
    :timeout => 120
  }
  Capybara::Poltergeist::Driver.new(app, options)
end
@house9

This comment has been minimized.

Show comment
Hide comment
@house9

house9 Sep 2, 2015

I was encountering Capybara::Poltergeist::TimeoutError errors in my feature specs under the following circumstances

  • js: true
  • and cdn references that were using https in my layouts

changing the cdn references to use Protocol-relative fixed the issue, i.e.:

<%= javascript_include_tag "//code.jquery.com/jquery-2.1.4.min.js" %>

this was running my specs on a vagrant box with ubuntu 14.04; phantomjs 1.9.0 and with poltergeist 1.5.1

house9 commented Sep 2, 2015

I was encountering Capybara::Poltergeist::TimeoutError errors in my feature specs under the following circumstances

  • js: true
  • and cdn references that were using https in my layouts

changing the cdn references to use Protocol-relative fixed the issue, i.e.:

<%= javascript_include_tag "//code.jquery.com/jquery-2.1.4.min.js" %>

this was running my specs on a vagrant box with ubuntu 14.04; phantomjs 1.9.0 and with poltergeist 1.5.1

@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Nov 14, 2015

Contributor

I'm closing this since it doesn't actually appear to be a specific issue but a collection of 5 or 6 different things. From a quick perusal it appears using the blacklist support added in 1.6.0 and telling phantomjs to ignore ssl errors may have fixed some of them for people, but other than that it's a lot of crosstalk. If anyone is still having issues with current poltergeist please open a new issue with all relevant details and if possible a minimal test case.

Contributor

twalpole commented Nov 14, 2015

I'm closing this since it doesn't actually appear to be a specific issue but a collection of 5 or 6 different things. From a quick perusal it appears using the blacklist support added in 1.6.0 and telling phantomjs to ignore ssl errors may have fixed some of them for people, but other than that it's a lot of crosstalk. If anyone is still having issues with current poltergeist please open a new issue with all relevant details and if possible a minimal test case.

@twalpole twalpole closed this Nov 14, 2015

@Vanuan

This comment has been minimized.

Show comment
Hide comment
@Vanuan

Vanuan Dec 8, 2015

@twalpole what is current phantomjs? 2.0.0 still not released.

Vanuan commented Dec 8, 2015

@twalpole what is current phantomjs? 2.0.0 still not released.

@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Dec 8, 2015

Contributor

@Vanuan Phantomjs 2.0.0 was released Jan 24, 2015 - so almost a year ago

Contributor

twalpole commented Dec 8, 2015

@Vanuan Phantomjs 2.0.0 was released Jan 24, 2015 - so almost a year ago

@Vanuan

This comment has been minimized.

Show comment
Hide comment
@Vanuan

Vanuan Dec 8, 2015

@twalpole still, there are no official binaries for Linux

Vanuan commented Dec 8, 2015

@twalpole still, there are no official binaries for Linux

@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Dec 8, 2015

Contributor

@Vanuan That really seems likes an issue to post over on the phantomjs project and not actually a poltergeist issue. You could also just compile it yourself for whatever platform you want to run it on.

Contributor

twalpole commented Dec 8, 2015

@Vanuan That really seems likes an issue to post over on the phantomjs project and not actually a poltergeist issue. You could also just compile it yourself for whatever platform you want to run it on.

@Senjai

This comment has been minimized.

Show comment
Hide comment
@Senjai

Senjai Dec 9, 2015

@twalpole I would be pro locking this issue down, as I suspect it will still generate new comments, and a lot of pings if that's something you'd be okay with.

Senjai commented Dec 9, 2015

@twalpole I would be pro locking this issue down, as I suspect it will still generate new comments, and a lot of pings if that's something you'd be okay with.

@teampoltergeist teampoltergeist locked and limited conversation to collaborators Dec 9, 2015

@twalpole

This comment has been minimized.

Show comment
Hide comment
@twalpole

twalpole Dec 9, 2015

Contributor

@Senjai Done

Contributor

twalpole commented Dec 9, 2015

@Senjai Done

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.