puma: Errno::EINVAL while running capybara tests in rails
Steps to reproduce
-
Use
Timecop
to freeze time pretty far back in time (e.g. 1970) -
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.
- Raise a more informative error. The
man select
on my system does give two reasons forEINVAL
so this is ambiguous to developers without really digging in. - Would it make sense to set a max value in this calculation, https://github.com/puma/puma/blob/master/lib/puma/reactor.rb#L282?
- 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)
I have managed to fix this https://gist.github.com/2rba/74d57775ac83ffcb0ff1da5eb5371212
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:
@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.