puma: Errno::EINVAL while running capybara tests in rails

Steps to reproduce

  1. Use Timecop to freeze time pretty far back in time (e.g. 1970)

  2. Use capybara visit function to go to a url

Expected behavior

Capybara should be able to go to the url.

Actual behavior

We get the following stack trace.

Error in reactor loop escaped: Invalid argument (Errno::EINVAL)
puma-3.11.0/lib/puma/reactor.rb:29:in `select'
puma-3.11.0/lib/puma/reactor.rb:29:in `run_internal'
puma-3.11.0/lib/puma/reactor.rb:154:in `block in run_in_thread'

System configuration

2.5.1 5.1.6 3.11.0 macOS High Sierra Version 10.13.2

Investigation

It seems pretty easy in hindsight, but the stack trace was being generated because the @sleep_for value was too large, https://github.com/puma/puma/blob/master/lib/puma/reactor.rb#L126. In our test runs, this value was 1526858764.467461.

I’m not sure if there is necessarily anything to fix here, but this was confusing for quite some time. Some possible ideas.

  1. Raise a more informative error. The man select on my system does give two reasons for EINVAL so this is ambiguous to developers without really digging in.
  2. Would it make sense to set a max value in this calculation, https://github.com/puma/puma/blob/master/lib/puma/reactor.rb#L282?
  3. Is there a more useful way to share this?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 28
  • Comments: 16 (2 by maintainers)

Most upvoted comments

Alternative quick-fix tip - don’t travel to future, travel to past only

After some investigations, in our case these errors are happening only when dates are stubbed to future date. When stubbed to past date there is no errors (guess because delta is negative 😄 ), so… just refactored everything to past.

Another option:

# features/support/env.rb
Capybara.server = :webrick

@2rba has a patch that fixes this problem for me. Can we please get this added to a release ASAP? I have just tested with the patch applied.

rspec 3.8 rails 5.2.2.1 capybara 3.15.0 puma 3.12.1 timecop 0.9.1

Upgraded from capybara (2.18.0) to capybara (3.10.1) and started receiving this error. Rolling back to 2.18.0 solved the problem for me. My current version of timecop is 0.9.1 and puma is 3.12.0.