-
Notifications
You must be signed in to change notification settings - Fork 31
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
Comments
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:
|
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.
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? |
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 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. |
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. |
Ok. For me, next week is Railsconf and May will be Faktory 1.0 and Sidekiq 6.0 launches. Perhaps June. |
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?The text was updated successfully, but these errors were encountered: