Editing job arguments and snoozing

[dgunay]

I have a job that I want to schedule and rerun on a nonlinear cadence (T-7 days, T-1 day, T-0 days, then stop).

I first implemented this by reinserting the job with an integer counting up to the next point in the cadence, but then I read about JobSnooze and wanted to try that. The code got a lot cleaner, but the problem now is that I don't have a way of indicating to the next worker that the snooze period should be different.

I could do something like directly update the job arguments myself with a query, but I'd prefer not to do that to avoid relying on unstable behavior. Is there a better way of accomplishing this within River?

[bgentry]

I don’t think we’re likely to add something for updating job args. The options I would try are:

1. Use the job attempt number minus the error count to determined how many times you’ve snoozed.
2. Enqueue a new job for each of the future attempt(s).

Can you see if either of those works for your use case?

Separate but related, I’ve been contemplating updating the logic around snoozing to not increment the attempt count (essentially undoing the fetch attempt increment upon snooze). And then we could track the snooze count separately (like in metadata). My thought is it will be more intuitive when looking at the attempt number and error count, though if you want to specifically tell how many times you’ve snoozed you’d have to pull that out of metadata. Curious if you have any thoughts on that.

[dgunay]

I think for my use case I'm just going to go back to inserting a new job for each future attempt.

Separate but related, I’ve been contemplating updating the logic around snoozing to not increment the attempt count (essentially undoing the fetch attempt increment upon snooze). And then we could track the snooze count separately (like in metadata). My thought is it will be more intuitive when looking at the attempt number and error count, though if you want to specifically tell how many times you’ve snoozed you’d have to pull that out of metadata. Curious if you have any thoughts on that.

When I read the docs, it was a little surprising to me that snoozing jobs worked by increasing the max number of attempts. That's just my reaction though, it makes some sense when you think about it, besides what you mentioned about being unable to easily track how many times a job was snoozed),

[bgentry]

Yeah, it’s essentially a side effect of the fact that all jobs get their attempt incremented upon fetch. When implementing snooze we didn’t do anything special to avoid that, which leads to some counterintuitive edge cases (like needing to account for this when calculating the next retry back off).