New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Backtrace propagation into the executor #810
Comments
Depending on you environment, you can configure backtrace filtering. It's not reasonable to rewrite this code to optimize for short backtraces. This is a good article about backtrace filtering in RSpec to help get you started. |
Please note that this is not that much about filtering, as it is about propagating the backtrace when running some code via concurrent-ruby executor. The filtering can be handled separately (although if the backtrace propagation would be handled, I think it would improve the out-of-box usability) |
In other words, the key thing in this desired outcome:
is not See Dynflow/dynflow#326 for real-world example of such a situation. Without that patch, it's next to impossible to find that
|
Any update here? |
Nobody is working on it at the moment. |
We did this as a workaround for the moment - still testing it out though: class ConcurrencyKlass
def self.execute(&block)
Concurrent::Promises.future {
begin
yield block
rescue => e
new_backtrace = [caller, e.backtrace].flatten
e.set_backtrace(new_backtrace)
CustomErrorHandler.send_error_to_error_alerting_system(e)
end
}
end
end and then used as such ConcurrencyKlass.execute { # Concurrent code here } |
When an error occurs within some code running inside concurrent-ruby executor, it ends up with something like this, while loosing the info about the true origin of the code:
Example:
Result:
Desired would be something like
This is very bad developer experience and makes it very hard to deal with the code that is using actors or other concurrent-ruby abstractions.
The text was updated successfully, but these errors were encountered: