feat(ActiveJob): Un-failing resets execution log - #124
Open
smudge wants to merge 1 commit into
Open
Conversation
smudge
added a commit
that referenced
this pull request
Aug 4, 2026
Previously, when a job's `retry_on` attempts ran out (resulting in a permanently failed job), un-failing that job would only allow for a single attempt, rather than resetting the attempts counter. For non-ActiveJobs, we can reset `attempts` back to `0`, but ActiveJobs have no equivalent SQL command and can only be reset via reserializing the job handler in Ruby (making this operation somewhat hostile to bulk operations). This PR aims to address that by checking if an ActiveJob was un-failed, and if so then checking if `attempts` was set to zero. ActiveJob has no persisted concept of a terminal failure state (i.e. this gem's `failed_at` column), so this gem also extends the serialized payload to include a `terminated_at` key, which survives the round trip as we do not need ActiveJob to reserialize this value when we un-fail jobs. stack-info: PR: #124, branch: smudge/stack/7
This was referenced Aug 4, 2026
smudge
marked this pull request as draft
August 4, 2026 23:14
smudge
added a commit
that referenced
this pull request
Aug 4, 2026
Previously, when a job's `retry_on` attempts ran out (resulting in a permanently failed job), un-failing that job would only allow for a single attempt, rather than resetting the attempts counter. For non-ActiveJobs, we can reset `attempts` back to `0`, but ActiveJobs have no equivalent SQL command and can only be reset via reserializing the job handler in Ruby (making this operation somewhat hostile to bulk operations). This PR aims to address that by checking if an ActiveJob was un-failed, and if so then checking if `attempts` was set to zero. ActiveJob has no persisted concept of a terminal failure state (i.e. this gem's `failed_at` column), so this gem also extends the serialized payload to include a `terminated_at` key, which survives the round trip as we do not need ActiveJob to reserialize this value when we un-fail jobs. stack-info: PR: #124, branch: smudge/stack/7
smudge
marked this pull request as ready for review
August 4, 2026 23:14
Previously, when a job's `retry_on` attempts ran out (resulting in an error raised to the worker, and eventually a permanently-failed job), un-failing that job would only allow for a single attempt, rather than restoring the job's `retry_on` budget. For non-ActiveJobs, we can reset `attempts` back to `0`, but ActiveJobs have no equivalent SQL command and can only be reset via reserializing the job handler in Ruby (making this operation somewhat hostile to bulk operations). This PR aims to address that by checking if an ActiveJob was terminated, and if so then checking if `attempts` was set to zero. ActiveJob has no persisted concept of a terminal failure state (i.e. this gem's `failed_at` column), so this gem extends the serialized payload with a `terminated_at` key. JobWrapper's `error` hook stamps it at the moment an error escapes ActiveJob's own retry machinery (i.e. the job exceeded ActiveJob's execution budget — 1 by default, or as configured by `retry_on`), marking the handoff to the worker's own retry backstop. The wrapper's `before` hook then resets `executions`/`exception_executions` whenever the marker is present and the row's `attempts` is zero, which can only occur via operator intervention. stack-info: PR: #124, branch: smudge/stack/7
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, when a job's
retry_onattempts ran out (resulting in a permanently failed job), un-failing that job would only allow for a single attempt, rather than resetting the attempts counter.For non-ActiveJobs, we can reset
attemptsback to0, but ActiveJobs have no equivalent SQL command and can only be reset via reserializing the job handler in Ruby (making this operation somewhat hostile to bulk operations). This PR aims to address that by checking if an ActiveJob was un-failed, and if so then checking ifattemptswas set to zero.ActiveJob has no persisted concept of a terminal failure state (i.e. this gem's
failed_atcolumn), so this gem also extends the serialized payload to include aterminated_atkey, which survives the round trip as we do not need ActiveJob to reserialize this value when we un-fail jobs.