-
Notifications
You must be signed in to change notification settings - Fork 2
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
Check for existing rebuilds #54
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's really two distinct types things going on here, so I think it would be worth splitting the PR in two — the first for the refactoring (which looks like it could go through like this OK) and then the second for changing the behaviour (which I think also really needs a test to show the new behaviour is working).
Yep, good shout. I've pulled out the refactoring into a separate PR - #55. |
This checks for an existing job matching the rebuild arguments. If one is found then the rebuild is skipped to stop the queue from bloating.
9179f8b
to
aaa3c58
Compare
The Sidekiq API doesn't work with Sidekiq's testing mode and we want to use the API to check for existing jobs, so switching the tests over to use the API seems like the simplest option.
This class is responsible for ensuring that jobs for the same legislature don't get queued up more than once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little concerned that if I remove the if
clause in the new add
method — i.e. making it simply
def add(country, legislature, source = nil)
RebuilderJob.perform_async(country, legislature, source)
"Queued rebuild for country=#{country} legislature=#{legislature} source=#{source}\n"
end
then the tests still pass…
This definitely seems to be the right abstraction, but I think finding it at the end of this PR makes it a little harder to follow. I'm wondering if it might make more sense to do this as two steps — firstly a 'clean' refactoring that maintains the old behaviour, but with the new Queue implementation. Then once we know that's working correctly, adding the 'skip if one exists' logic.
a62b715
to
2976cbf
Compare
This checks for existing jobs before re-queueing them, which should help keep the size of the rebuild queue down.
Fixes #37
Note to merger
Make sure the following have been done before merging this:
master
once Add Rubocop #53 has been merged.