Skip to content
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

Avoid raising and re-queueing when the remote resource is not found #17745

Merged
merged 1 commit into from
Aug 6, 2018

Conversation

bdunne
Copy link
Member

@bdunne bdunne commented Jul 23, 2018

_log.info("Invoking task #{action} on collection #{collection_name}, object #{obj.id}, with args #{post_args}")
obj.send(action, post_args)
rescue RuntimeError => err
raise unless err.message =~ /couldn't find resource with 'id' \["\d+"\]/i
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This regex feels too specific and the message could change a little and suddenly break this. Does it raise a useful exception class we can rescue instead? If not, is /couldn't find resource with 'id'/i enough?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not raise a useful exception class. That's the entire error message.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we want to raise a UnretryableException or something like that (better name) and have invoke_tasks_remote catch it, log it and move on. I think swallowing it here hides the fact that we're explicitly skipping re-queueing.

Copy link
Member

@carbonin carbonin Jul 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can rescue just around the collection.find(id) call on line 123?

Then we can avoid the conditional entirely I think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe?

obj = collection.find_by(:id => id)
if obj
  _log.info("Invoking task #{action} on collection #{collection_name}, object #{obj.id}, with args #{post_args}")
  obj.send(action, post_args)
end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kbrock does the API client return nil for find_by rather than an exception?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carbonin aah - not sure. I was assuming it followed AR conventions - which is probably wrong
thanks

Copy link
Member

@kbrock kbrock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice focused solution.

Lets get this in

_log.info("Invoking task #{action} on collection #{collection_name}, object #{obj.id}, with args #{post_args}")
obj.send(action, post_args)
rescue RuntimeError => err
raise unless err.message =~ /couldn't find resource with 'id' \["\d+"\]/i
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe?

obj = collection.find_by(:id => id)
if obj
  _log.info("Invoking task #{action} on collection #{collection_name}, object #{obj.id}, with args #{post_args}")
  obj.send(action, post_args)
end

@@ -68,6 +68,8 @@ def invoke_tasks_remote(options)
begin
remote_connection = InterRegionApiMethodRelay.api_client_connection_for_region(region, remote_options[:userid])
invoke_api_tasks(remote_connection, remote_options)
rescue ManageIQ::API::Client::ResourceNotFound => err
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good way to rescue the error, but wouldn't this bail out before all of the resources were processed in invoke_api_tasks?

Why not leave this rescue inside the resource loop in that method?

@miq-bot
Copy link
Member

miq-bot commented Aug 6, 2018

Checked commit bdunne@a6343cf with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
3 files checked, 0 offenses detected
Everything looks fine. ⭐

@jrafanie
Copy link
Member

jrafanie commented Aug 6, 2018

I'm good with this, @carbonin was your comment addressed?

Copy link
Member

@carbonin carbonin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me 👍

@carbonin carbonin self-assigned this Aug 6, 2018
@carbonin carbonin merged commit f57d63f into ManageIQ:master Aug 6, 2018
@carbonin carbonin added this to the Sprint 92 Ending Aug 13, 2018 milestone Aug 6, 2018
@bdunne bdunne deleted the bz_1599754 branch August 6, 2018 21:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants