Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Add retry_on/discard_on for better exception handling #25991
Declarative exception handling of the most common kind: retrying and discarding.
class RemoteServiceJob < ActiveJob::Base retry_on Net::OpenTimeout, wait: 30.seconds, attempts: 10 def perform(*args) # Might raise Net::OpenTimeout when the remote service is down end end class SearchIndexingJob < ActiveJob::Base discard_on ActiveJob::DeserializationError def perform(record) # Will raise ActiveJob::DeserializationError if the record can't be deserialized end end
discard_on Net::OpenTimeout, retries: 10, wait: 30.seconds
rescue_from Net::OpenTimeout, retries: 10, wait: 30.seconds do |error| # We failed to connect ten times; give up and send someone an email or something end
Mostly, I like the fact this clearly states what happens when we run out of retries...
Ah, I see what you mean @matthewd. Actually what should happen after we try to retry a bunch of time and fail is that we should reraise and let the queue deal with it. Will fix that!
(Though I guess there's still an argument for ALSO allowing custom logic at that point, but).
FWIW, I think that's the thing I was arguing: if I write a custom
.. including on the new