The issue here is that some ActiveJob-enqueued jobs would include the @job ivar in their serialized handler, which is redundant with @job_data and only existed for memoization purposes. We can use Ruby's encode_with API to ensure that we only encode @job_data into the handler.
Including @job also had the side-effect of causing DeserializationErrors and permanently failing jobs in cases where there would otherwise be a retryable NameError. Whether a missing constant should result in a DeserializationError is kind of a separate question, but since ActiveJob's stance seems to be to encode the class name as a string and only .constantize it inside of the perform, I think that it's not surprising behavior to let the NameError (and subsequent retries) occur. DeserializationError is really supposed to be only for cases where we fundamentally can't even attempt the job and allow the normal pattern of exception-handling to occur.
smudge
commented
1 year ago
This should address #23.
The issue here is that some ActiveJob-enqueued jobs would include the
@jobivar in their serialized handler, which is redundant with@job_dataand only existed for memoization purposes. We can use Ruby'sencode_withAPI to ensure that we only encode@job_datainto the handler.Including
@jobalso had the side-effect of causingDeserializationErrorsand permanently failing jobs in cases where there would otherwise be a retryableNameError. Whether a missing constant should result in aDeserializationErroris kind of a separate question, but sinceActiveJob's stance seems to be to encode the class name as a string and only.constantizeit inside of the perform, I think that it's not surprising behavior to let theNameError(and subsequent retries) occur.DeserializationErroris really supposed to be only for cases where we fundamentally can't even attempt the job and allow the normal pattern of exception-handling to occur.