Feature Request: Callbacks/Middlewares for Handling Jobs at Risk of Loss in reliable_push about sidekiq HOT 4 CLOSED

I've seen very little demand for this type of functionality so I don't plan on implementing this myself. If Redis is down, we have no access to reliable storage. Sidekiq cannot depend on log output or the filesystem for a reliable storage between reboots. If you want to provide additional safety with your own patches, I think that's great. If you want to submit a PR with changes which make your patches more maintainable, I'd welcome them.

from sidekiq.

Hi Mike,

Thanks for your prompt response. We understand your concerns, and we appreciate your suggestion to provide additional safety with our own patches.

To address the potential loss of jobs during unexpected process exits, our proposal is inspired by the sidekiq_retries_exhausted hook. We don't intend for Sidekiq to rely on log output, the filesystem, or any specific storage mechanism. Instead, we envision allowing the application using Sidekiq to decide how to proceed with the unpushed jobs.

We're considering two potential methods like for example:

1. reliable_push_limit_reached:
   This hook would be triggered when a limit is reached, enabling users to take specific actions for individual jobs.

   reliable_push_limit_reached do |job|
     # Custom actions for handling the job
   end

2. reliable_push_jobs_on_exit:
   This hook would be invoked when jobs are in danger of being lost due to process exits, providing an opportunity for users to implement recovery strategies.

   reliable_push_jobs_on_exit do |jobs|
     # Custom actions for handling the list of jobs
   end

About contributing to a Sidekiq Pro feature, what's the best way to go about it? If you have some guidance, that would be great.

Thanks again,

from sidekiq.

I'm not interested in further refinement of this feature. I don't believe your suggestions would add any more real world reliability. It requires the user to provide the code, would be hard to integration test and infrequently executed.

Look into reconciliation instead: https://www.mikeperham.com/2014/05/27/the-reconciliation-step/

from sidekiq.

Alright,
We are not entirely sure how distinct this would be from 'sidekiq_exhausted_retries' on the server side, as both aim to provide an alternative when Sidekiq can't do anything else with the jobs and to help with the 'reconciliation'.

In any case, thanks once more. We'll figure out how to handle it on our end.

from sidekiq.