Tuning retry based on ActiveJob Exceptions implementation #4
Conversation
testapp/app/jobs/test_job.rb
Outdated
| @@ -1,9 +1,16 @@ | |||
| # frozen_string_literal: true | |||
|
|
|||
| class TestJob < ApplicationJob | |||
| class CustomError < StandardError; end | |||
|
|
|||
| retry_on(CustomError, wait: 5, attempts: 3, queue: :retry) do | |||
There was a problem hiding this comment.
what will the redis key look like for the retry queue?
There was a problem hiding this comment.
It would be prefixed with queue:, queue:retry in this case
There was a problem hiding this comment.
It's prefixed here https://github.com/sailor/quiq/blob/master/lib/quiq/scheduler.rb#L47
| klass = Object.const_get(payload['job_class']) | ||
| args = payload['arguments'] | ||
| job = klass.deserialize(payload) |
There was a problem hiding this comment.
Question: is it a rails/activejob primitive? If so it means that the system won't be usable outside of the rails ecosystem.
There was a problem hiding this comment.
maybe we should use if defined? ActiveJob here
There was a problem hiding this comment.
Yes, the retry mechanism is a rails/activejob primitive, but the serialize(which is used in Quiq::Client#push) and deserialize are probably not.
if defined? ActiveJob could be done during the server booting, wdyt?
ActiveJob has a built-in retry mechanism.
https://github.com/rails/rails/blob/6-0-stable/activejob/lib/active_job/exceptions.rb#L50-L67
By deserializing the job message properly, we can get the retry working easily with Quiq.