Skip to content
  • John Hawthorn's avatar
    5d9359bb
    Use ActiveJob 5.2 retry logic for old jobs · 5d9359bb
    John Hawthorn authored
    Rails 6 introduces retries per-exception, instead of a global count of
    retries. Because ActiveJob 5.2 doesn't serialize the execution count
    per-exception, when ActiveJob 6.0 picks up an "old" job it can't know
    the exception count in the new format.
    
    This can also be an issue if AJ 6.0 serializes a new job with
    exception_executions which is later picked up by AJ 5.2, which would
    clear exception_executions (since it has no knowledge of it).
    
    Previously we handled this by resetting exception_executions, if it
    wasn't defined on a job, which could result in the worst case retrying
    the job 2x the times we should.
    
    This commit changes how we handle loading a legacy job: instead of
    resetting exception_executions, we instead will always use the global
    executions count.
    
    This way, jobs which only have one retry_on (and didn't have a behaviour
    change in AJ 6) are backwards-and-forwards-compatible with counts
    respected exactly.
    
    Jobs with multiple retry_on will revert to the AJ5.2 behaviour if they
    were ever run under AJ5.2.
    5d9359bb
    Use ActiveJob 5.2 retry logic for old jobs
    John Hawthorn authored
    Rails 6 introduces retries per-exception, instead of a global count of
    retries. Because ActiveJob 5.2 doesn't serialize the execution count
    per-exception, when ActiveJob 6.0 picks up an "old" job it can't know
    the exception count in the new format.
    
    This can also be an issue if AJ 6.0 serializes a new job with
    exception_executions which is later picked up by AJ 5.2, which would
    clear exception_executions (since it has no knowledge of it).
    
    Previously we handled this by resetting exception_executions, if it
    wasn't defined on a job, which could result in the worst case retrying
    the job 2x the times we should.
    
    This commit changes how we handle loading a legacy job: instead of
    resetting exception_executions, we instead will always use the global
    executions count.
    
    This way, jobs which only have one retry_on (and didn't have a behaviour
    change in AJ 6) are backwards-and-forwards-compatible with counts
    respected exactly.
    
    Jobs with multiple retry_on will revert to the AJ5.2 behaviour if they
    were ever run under AJ5.2.
Loading