You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks in advance for making this Gem 😄. Our team has been enjoying it for a long time.~
However, as we also use Rspec in our automation systems, I found that sometimes our test would fail with a DeadWorker. This DeadWorker makes our investigation a little bit difficult. By digging into your library code more, I found that the fact that our tests would fail with DeadWorker is a consequence of:
When something like expect{a}.to be b fail, Rspec will raise a RSpec::Expectations::ExpectationNotMetError, which isn't a StandardError
We are using Parallel with in_processes so many of our code will be executed on a forked process.
I have a small example so you could also have a try:
require'rspec/expectations'require'parallel'# This line will fail and the last thing in the rspec report is a Parallel::DeadWorkerParallel.each(1..1,in_processes:1){|x| raiseRSpec::Expectations::ExpectationNotMetError}# This line will leave the correct exception as the exception happens in the main process and 'kills' the processParallel.each(1..1,in_threads:1){|x| raiseRSpec::Expectations::ExpectationNotMetError}
As I don't really know the designing details of process_incoming_jobs, this Issue is mainly for asking:
Are there any concerns so that you guys didn't choose to rescue all the exceptions in process_incoming_jobs?
We could patch what we need in our own system. But do you think it is worthy to modify the process_incoming_jobs so it could catch Exception? Or is there any other thing that might be better? We benefit from the open source community a lot so I would like to submit a PR for this. Feels like this could be something that everyone could run into, especially when using libraries such as Rspec that raises non-StandardError.
The text was updated successfully, but these errors were encountered:
Yeah it might be a good idea to rescue all ... since it's done in a fork and when we don't things get weird ...
The initial implementation was done because it is a common best practice to only rescue StandardError and I did not want to have to think through all the weird edge-cases.
Please try a PR that rescues Exception instead and see if the tests are happy with that.
Thanks for reply~ I see. Right, it is a common best practice to only rescue StandardError. All tests passed on my local machine so I have created a PR #269.
Thanks in advance for making this Gem 😄. Our team has been enjoying it for a long time.~
However, as we also use Rspec in our automation systems, I found that sometimes our test would fail with a DeadWorker. This DeadWorker makes our investigation a little bit difficult. By digging into your library code more, I found that the fact that our tests would fail with DeadWorker is a consequence of:
expect{a}.to be b
fail, Rspec will raise a RSpec::Expectations::ExpectationNotMetError, which isn't a StandardErrorin_processes
so many of our code will be executed on a forked process.I have a small example so you could also have a try:
I tried to make a small change that lets the rescue (https://github.com/grosser/parallel/blob/master/lib/parallel.rb#L472) to catch
Exception
and after the changes, our annoying DeadWorker was resolved.As I don't really know the designing details of process_incoming_jobs, this Issue is mainly for asking:
Exception
? Or is there any other thing that might be better? We benefit from the open source community a lot so I would like to submit a PR for this. Feels like this could be something that everyone could run into, especially when using libraries such as Rspec that raises non-StandardError.The text was updated successfully, but these errors were encountered: