Tuning retry based on ActiveJob Exceptions implementation#4
Tuning retry based on ActiveJob Exceptions implementation#4tzzzoz wants to merge 5 commits intosailor:masterfrom
Conversation
testapp/app/jobs/test_job.rb
Outdated
| 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
| # Then load the definition of the job + deserialize it to a job object | ||
| 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.