Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event for when retries are exhausted #38

Open
nathanpalmer opened this issue Apr 12, 2019 · 5 comments
Open

Event for when retries are exhausted #38

nathanpalmer opened this issue Apr 12, 2019 · 5 comments

Comments

@nathanpalmer
Copy link
Contributor

I'm wondering if there is a way to perform an action after the retries have been exhausted. Similar to the sidekiq_retries_exhausted method. Is this possible with Faktory?

@mperham
Copy link
Contributor

mperham commented Apr 12, 2019

There's no way today. Since Faktory handles the retry tracking and execution, the worker process becomes simpler but dumber. This is one of those ways. Possible things we can do:

  • API to scan for new Dead jobs
  • stream job lifecycle (e.g. job death) events from Faktory to a listening Worker process
  • make the FAIL command return some state/info, e.g. next retry time or nil, etc.

@nathanpalmer
Copy link
Contributor Author

Got it. I thought that might be the case. It seems the most straightforward way to potentially handle this is the last item you mentioned.

make the FAIL command return some state/info, e.g. next retry time or nil, etc.

Given that the worker could consume that response and trigger the event if it was on a final retry. Is that possible? Does the logic determining retry happen synchronously?

@mperham
Copy link
Contributor

mperham commented Apr 19, 2019

I like this idea but it brings up a limitation in the protocol. Most commands respond with "OK" when they really should response with a JSON blob like { "result": "OK" } that would allow Faktory to include more metadata like you are requesting. Yes, it is all synchronous.

We're right at the cusp of 1.0 so I'm not sure if I should ship 1.0 and delay this change to 2.0 or overhaul the protocol again, force all worker libraries to upgrade and then ship 1.0. I'm leaning toward the former. This is a nice to have but not critical IMO.

@nathanpalmer
Copy link
Contributor Author

Got it. Yeah, from a timing perspective on our side we're going to need something like this before we can move our main backend over to using Faktory. However, we're possibly a month or two away from that.

@mperham
Copy link
Contributor

mperham commented Apr 22, 2019

Ok. For me, next week is Railsconf and May will be Faktory 1.0 and Sidekiq 6.0 launches. Perhaps June.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants