search

contribsys / faktory_worker_ruby

Faktory worker for Ruby
GNU Lesser General Public License v3.0
214 stars 31 forks source link

Event for when retries are exhausted #38

Open nathanpalmer opened 5 years ago

nathanpalmer commented 5 years ago

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 commented 5 years ago

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:

nathanpalmer commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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