Unexpected behavior with until_and_while_executing #711
Comments
|
Please checkout v7.1.26 https://github.com/mhenrixon/sidekiq-unique-jobs/releases/tag/v7.1.26 as it has quite a few fixes for until and while executing |
|
Also, if you are still having trouble: https://github.com/mhenrixon/sidekiq-unique-jobs/releases/tag/v7.1.27 (especially if you are using redis-namespace). |
|
IMHO, the expected behavior is that a new job can only be created after the previous job is completed, @mhenrixon, am I right? class XlsxAppointmentsUpserterJob
include Sidekiq::Job
sidekiq_options queue: 'exports', retry: 5, lock: :until_and_while_executing, on_conflict: { client: :log, server: :reject }
def perform
require 'pry'; binding.pry
end
endjob_test.movRails 7 |
Use until_executed |
|
This also threw me for quite a while. I expected "new job can only be created after the previous job is completed". This is probably the cause of a lot of confusion and open issues around until_and_while_executing And the readme appears incorrect: The lock is not removed until the perform is actually completed. |
|
have configuration like this So after investigation i found that it use all lock args That is reason why digest is different and it allow multiple jobs I can not find way how generate it only based on queue and class name |
Describe the bug
I'm not sure if this is a bug or if I'm misunderstanding the documentation/usage of
:until_and_while_executing. While:until_and_while_executingproperly locks jobs which are queued but haven't started executing (e.g.perform_in(1.hour, ...)), it does not seem to correctly lock through execution of the job.Expected behavior
From reading the documentation, I'd expect
:until_and_while_executingto lock until execution has started (seeuntil_executed) AND through execution of the job (seewhile_executing).Current behavior
The first subsequent job will be cancelled correctly, while the next job will not be cancelled, and so on alternating in that manner, i.e.
Rails console
The IDs correspond with the Sidekiq output provided below.
Sidekiq output
Sidekiq panel
Note that complete here is indicated the job is dead, as handled by
sidekiq-status.config/initializers/sidekiq.rb
app/sidekiq/test_job.rb
Additional context
Desired usage:
1. Cron schedules a job MyJob every ~10 minutes to update data and do various work.
2. The amount of data handled via MyJob can vary considerably and thus may take over 10 minutes.
3a. In the case that 10 minutes has elapsed and the previous MyJob is complete, MyJob should be run again.
3b. In the case that MyJob had a lot of work to do and still hasn't finished after 10 minutes, the new MyJob should be cancelled and not retried. The same process will repeat every 10 minutes until the original MyJob instance has finished and a new one is then executed.
The text was updated successfully, but these errors were encountered: