Open bmhatfield opened 8 years ago
I did some playing around with this, and it looks like Celluloid
's abort
method is making it up the call stack further than expected. Adding some simplistic puts
to track the exception chain:
** RAISING EXCEPTION IN on_complete (chef_response.rb:24)
** In run_request (connection.rb:107) rescue block
** in raw_request (resource.rb:13) rescue block
** In partial_search (client.rb:250) rescue block: Ridley::Errors::HTTPBadRequest
Altering partial_search
to handle the exception seems to help:
def partial_search(index, query = nil, attributes = [], options = {})
@resources_registry[:search_resource].partial(index, query, Array(attributes), @resources_registry, options)
rescue Errors::HTTPError => ex
puts "** In partial_search rescue block: #{ex.class}"
abort(ex)
end
Looking at client.rb
, however, seems that no resource is protected in this manner, which gives me pause as to the correct approach, and slows me from simply sending a PR with my changes.
What do you recommend? I don't think I can solve this problem directly by catching the relevant exceptions in my code, as they occur in a different thread, I think. I could 'open up' Ridley from my code or run a fork of this Gem, but I am not really interested in either of those workarounds.
I would be happy to submit a PR, but I don't really feel like I understand the intent of this current abort and catch exception structure, especially because it appears to fall short of what's needed to prevent the outer actors from crashing.
Thoughts?
Subsequent requests to the same process fail with:
I'm not really sure how I am supposed to be handling this error from my API's perspective - I don't know if a given search query is going to be valid or not.
Should I rescue the
Ridley::Errors::HTTPBadRequest
exception? Can I reinitialize the actor?