feat: add max_retry_backoff option to job runner #53
Conversation
|
This looks very useful. I have a sentinel job that performs some cleanup once a channel is empty. It does that with checkpoints but a long-running sentinel will end up with an absurdly high backoff as there is no option for linear retries. Looks like this PR would allow me effectively avoid using exponential backoff in the first place. I wonder if @Diggsey has abandoned this project? PRs have been sitting for a long time despite very active GH activity... |
|
No conflicts with base branch, please merge it!!! |
Diggsey
left a comment
Diggsey
left a comment
There was a problem hiding this comment.
Thanks for the PR and sorry for the delay in reviewing!
| SET | ||
| attempt_at = CASE WHEN mq_msgs.attempts = 1 THEN NULL ELSE NOW() + mq_msgs.retry_backoff END, | ||
| attempts = mq_msgs.attempts - 1, | ||
| retry_backoff = CASE WHEN max_retry_text IS NULL THEN mq_msgs.retry_backoff * 2 ELSE LEAST(mq_msgs.retry_backoff * 2, max_retry_text) END |
There was a problem hiding this comment.
I think this condition is redundant, it can just be:
retry_backoff = LEAST(mq_msgs.retry_backoff * 2, max_retry_text)I think this should also be called max_retry_interval rather than max_retry_text
4 participants
A solution to #19 based on StructionSite@0489b51