You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, before LISTEN/NOTIFY support, each scheduler in the multi-scheduler was called in succession using map(if state is nil, like it was from the poll), but now with the use of the any? enumerator only the schedulers up until the first one that returns true will be called.
I think with the change in v1.3.1 to extract the poller logic we have uncovered an unexpected consequence from the change to the multi-scheduler.
If you execute GOOD_JOB_QUEUES="other_queue:2;*" bundle exec good_job there is only SQL debug output for polling the 'other_queue'.
So the bug is that if you restart the job workers while a queue has jobs in it, the old jobs are never picked up(until a notifier message shows up at least) for any queue but the first one listed in the scheduler list when they are restarted.
I tested against v1.3.0, and you can see the SQL output from checking both queue lists in the multi-scheduler.
I don't know this codebase well enough to know how the changes in 1.3.1 are now causing this behavior, I would have expected this behavior to have started back when the LISTEN/NOTIFY stuff was implemented...
The text was updated successfully, but these errors were encountered:
Previously, before LISTEN/NOTIFY support, each scheduler in the multi-scheduler was called in succession using
map
(if state is nil, like it was from the poll), but now with the use of theany?
enumerator only the schedulers up until the first one that returns true will be called.I think with the change in v1.3.1 to extract the poller logic we have uncovered an unexpected consequence from the change to the multi-scheduler.
If you execute
GOOD_JOB_QUEUES="other_queue:2;*" bundle exec good_job
there is only SQL debug output for polling the 'other_queue'.So the bug is that if you restart the job workers while a queue has jobs in it, the old jobs are never picked up(until a notifier message shows up at least) for any queue but the first one listed in the scheduler list when they are restarted.
I tested against v1.3.0, and you can see the SQL output from checking both queue lists in the multi-scheduler.
I don't know this codebase well enough to know how the changes in 1.3.1 are now causing this behavior, I would have expected this behavior to have started back when the LISTEN/NOTIFY stuff was implemented...
The text was updated successfully, but these errors were encountered: