fix crash by returning after notify_failure

[bronson]

Guard crashes on my machine unless I insert this return statement. Dunno if it's the right fix.

What's funny is that the bug seems to be introduced as a result of RuboCop? 846ca48

Here's the crash:

07:43:32 - ERROR - Guard::RSpec failed to achieve its <run_all>, exception was:
> [#CD64AA63CA3A] NoMethodError: undefined method `match' for nil:NilClass
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec/notifier.rb:32:in `_parse_summary'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec/notifier.rb:12:in `notify'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec/runner.rb:107:in `_process_run_result'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec/runner.rb:45:in `block in _run'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec/runner.rb:44:in `tap'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec/runner.rb:44:in `_run'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec/runner.rb:24:in `run_all'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec.rb:33:in `block in run_all'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec.rb:48:in `_throw_if_failed'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-rspec-4.5.0/lib/guard/rspec.rb:33:in `run_all'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:82:in `block in _supervise'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:79:in `catch'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:79:in `_supervise'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:22:in `block (3 levels) in run'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:119:in `block (2 levels) in _run_group_plugins'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:117:in `each'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:117:in `block in _run_group_plugins'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:116:in `catch'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:116:in `_run_group_plugins'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:21:in `block (2 levels) in run'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:20:in `each'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:20:in `block in run'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/lumberjack-1.0.9/lib/lumberjack.rb:32:in `unit_of_work'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/runner.rb:18:in `run'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/commander.rb:82:in `run_all'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/internals/queue.rb:42:in `block in _run_actions'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/internals/queue.rb:37:in `each'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/internals/queue.rb:37:in `_run_actions'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/internals/queue.rb:21:in `process'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/commander.rb:43:in `start'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/cli/environments/valid.rb:16:in `start_guard'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/cli.rb:113:in `start'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/aruba_adapter.rb:32:in `execute'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/lib/guard/aruba_adapter.rb:19:in `execute!'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/gems/guard-2.11.1/bin/guard:11:in `<top (required)>'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/bin/guard:23:in `load'
> [#CD64AA63CA3A] /Users/bronson/.gem/ruby/2.2.0/bin/guard:23:in `<main>'
07:43:32 - INFO - Guard::RSpec has just been fired

[coveralls]

Coverage increased (+0.0%) to 97.23% when pulling 04a79b5 on bronson:patch-1 into 42fb4b7 on guard:master.

[coveralls]

Coverage increased (+0.0%) to 97.23% when pulling 04a79b5 on bronson:patch-1 into 42fb4b7 on guard:master.

[e2]

Thanks. This should have a test at least - but I don't have enough info to reproduce the problem.

Could you add STDERR.puts [formatter_tmp_file,$!].inspect in this rescue block to see what went wrong?:

https://github.com/bronson/guard-rspec/blob/patch-1/lib/guard/rspec/runner.rb#L77

I'm guessing the file doesn't exist or something. The code is bad there, because it should at least show an error in that case, and not hide the exception.

I don't mind pulling this change in - I'd just prefer to find the actual cause and prevent it from ever causing trouble again.

[bronson]

Always happy to understand a bug rather than just shooting in the dark.

Your guess is close. The entire tmp directory doesn't exist (since this isn't a Rails project). Should that be /tmp?

FOMATTER_TMP_FILE: "tmp/rspec_guard_result"
LINES: nil
SUMMARY: nil
FAILED PATHS: nil

And $! is #<Errno::ENOENT: No such file or directory @ rb_sysopen - tmp/rspec_guard_result>

[bronson]

Hm, creating a tmp directory in the project dir didn't change anything. Still bombs out because the file is missing. tmp is always empty.

[bronson]

So the file can't be created because, get this, somebody didn't require 'fileutils'. The missing require was hidden because all exceptions are getting slurped up.

I think the comment at rspec_formatter.rb:74 is not actually true. If it had printed something, this would have been a 2 minute bughunt.

[bronson]

Adding the require seems to fix everything. But, quietly creating a tmp dir in a project that doesn't need one seems like an antifeature to me.

[coveralls]

Coverage decreased (-0.21%) to 97.01% when pulling 9cb1cc9 on bronson:patch-1 into 42fb4b7 on guard:master.

[coveralls]

Coverage increased (+0.0%) to 97.23% when pulling 9cb1cc9 on bronson:patch-1 into 42fb4b7 on guard:master.

[e2]

Thanks for investigating!

If it had printed something, this would have been a 2 minute bughunt.

That's why I love getting structured exceptions and stack traces - instead of the "user friendly" idea of "not crashing". Especially since most RSpec users are developers anyway.

The whole gem probably needs some reviewing - though I guess most people would be too afraid to touch anything (since it's a popular gem - and quite complex too).

But, quietly creating a tmp dir in a project that doesn't need one seems like an antifeature to me

That's because the formatter has to somehow communicate (the test results) with the main process. An environment variable may be a better idea - then the temp file could be in /tmp or whatever.

I might look into it, but I can't make promises.

[bronson]

Thanks! I'd be annoyed except I'm not volunteering for the cleanup either... I'll take what I can get :)

I suppose the main process forks the formatter? Could it read the formatter's output over a pipe? I wrote that for Shrimple, could look into doing it here too.

[e2]

That's been considered (for other purposes). The issue is: when using a pipe, you'll get colored ANSI output - which means there would be an extra step of filtering, etc. That's why a custom formatter is used - because that's how you can get RSpec to create "normal" output.

Also, the file with output is useful to keep anyway - beyond just guard-rspec (for other tools like edit integration, etc.). So we quickly get into some kind of persistent storage, e.g. files, redis, or at least a socket. Everything else is just a poor-man's workaround.

Overall guard (and plugins) would benefit from persistent storage anyway - but that's a project in of itself.