mbj
Improve error UX?
I recently had a neutral failure due to an unparser bug (https://github.com/mbj/unparser/issues/311)
mutant spat out a ton of output that made it harder to see what actually went wrong. It seems like there are a lot more cases where i get a marshal data too short exception with no other context than i remember as of a couple years back. Is there a way that could be handled more gracefully/recognized as not helpful information? For unparser failures in particular, it would be nice to just highlight that the code failed to round-trip. Maybe there could be an explicit check for that on a neutral failure and it could tell the user there was a parsing or unparsing bug?
Example output:
The following exception was raised while reading the killfork result:
ArgumentError
marshal data too short
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:134:in `load'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:134:in `load_result'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:124:in `read_child_result'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:84:in `call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/procto.rb:19:in `call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:242:in `block (2 levels) in call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:46:in `block in with'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:45:in `pipe'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:45:in `with'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:241:in `block in call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:46:in `block in with'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:45:in `pipe'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:45:in `with'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/isolation/fork.rb:240:in `call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/env.rb:140:in `run_mutation_tests'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/env.rb:61:in `cover_index'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel/worker.rb:122:in `call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel/worker.rb:122:in `block in call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel/worker.rb:121:in `loop'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel/worker.rb:121:in `call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel/worker.rb:42:in `block in start'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel/worker.rb:31:in `fork'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel/worker.rb:31:in `start'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel.rb:26:in `block in workers'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel.rb:25:in `initialize'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel.rb:25:in `new'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel.rb:25:in `workers'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/parallel.rb:15:in `async'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/runner.rb:20:in `run_mutation_analysis'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/runner.rb:12:in `call'
/tmp/bundle/ruby/2.7.0/gems/unparser-0.6.4/lib/unparser/either.rb:115:in `bind'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/cli/command/environment/run.rb:46:in `action'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/cli/command.rb:81:in `execute'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/lib/mutant/cli/command.rb:55:in `call'
/tmp/bundle/ruby/2.7.0/gems/mutant-0.11.6/bin/mutant:47:in `<top (required)>'
/tmp/bundle/ruby/2.7.0/bin/mutant:25:in `load'
/tmp/bundle/ruby/2.7.0/bin/mutant:25:in `<top (required)>'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/cli/exec.rb:58:in `load'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/cli/exec.rb:58:in `kernel_load'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/cli/exec.rb:23:in `run'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/cli.rb:483:in `exec'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/cli.rb:31:in `dispatch'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/cli.rb:25:in `start'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.3.11/exe/bundle:48:in `block in <top (required)>'
/usr/local/lib/ruby/site_ruby/2.7.0/bundler/friendly_errors.rb:103:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.3.11/exe/bundle:36:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
@dgollahon that specific crash is solved with unparser-0.6.5 and these crashes are "rare" in sense of: They are 'serious bugs' in the ecosystem. I agree they should be easier to track down, but so far all of them would have been shown in the proposed:
mutant environment verify
Subcommand, we could run whenever mutant environment run (aliased to mutant run): fails with such a crash. So I'm a bit tied if we should make this hard crash nicer, or foucs the energy on the verify command that has lots of other use cases.
