Summary
The documented way to update a dynamic recurring task is to unschedule it and then schedule it again with the same key and updated options:
SolidQueue.unschedule_recurring_task("my_dynamic_task")
SolidQueue.schedule_recurring_task(
"my_dynamic_task",
class: "MyJob",
schedule: "every 10 minutes"
)
However, if the deletion and recreation both happen before the scheduler's next dynamic-task poll, the scheduler does not pick up the new schedule. It continues using the old in-memory task definition.
This also occurs if both operations are wrapped in a single database transaction, because the scheduler can never observe the row as absent.
Environment
- Solid Queue: 1.7.0
- Rails: 8.1
- Ruby: 3.3.11
- Database: mysql2 0.5.1
- Scheduler mode: default
config/queue.yml:
development:
dispatchers:
- polling_interval: 5 # seconds
batch_size: 500
workers:
- queues: "*"
threads: 1
processes: 1
polling_interval: 5 # seconds
scheduler:
dynamic_tasks_enabled: true
polling_interval: 5 # seconds
Reproduction
Start a scheduler with dynamic tasks enabled and a short polling interval.
Schedule a task with a schedule that runs frequently:
SolidQueue.schedule_recurring_task(
"dynamic_task",
class: "ProbeJob",
schedule: "every second"
)
After the scheduler has picked up the task, immediately replace it using the documented API:
SolidQueue.unschedule_recurring_task("dynamic_task")
SolidQueue.schedule_recurring_task(
"dynamic_task",
class: "ProbeJob",
schedule: "every minute"
)
Ensure both calls complete before the next polling_interval elapses.
Actual behavior
The scheduler continues to run the original every second schedule. The replacement task record is present in solid_queue_recurring_tasks with schedule: "every minute", but its updated schedule is not used until the scheduler restarts.
Expected behavior
Using the documented unschedule-and-reschedule sequence should replace the active dynamic task definition, even when both database operations occur between scheduler polls.
Alternatively, if this timing constraint is intentional, the documentation should explicitly require waiting until the scheduler observes the deletion before recreating the task with the same key.
Why this happens
Scheduler::RecurringSchedule#reschedule_dynamic_tasks reloads dynamic tasks, then performs only key-based reconciliation:
def schedule_created_dynamic_tasks
RecurringTask.dynamic.where.not(key: scheduled_tasks.keys).each do |task|
schedule_task(task)
end
end
def unschedule_deleted_dynamic_tasks
(scheduled_tasks.keys - RecurringTask.pluck(:key)).each do |key|
scheduled_tasks[key].cancel
scheduled_tasks.delete(key)
end
end
When the row is deleted and recreated with the same key between polls:
scheduled_tasks still contains "dynamic_task" from the old definition.
- The database also contains
"dynamic_task" from the new definition.
where.not(key: scheduled_tasks.keys) returns no row.
- The subtraction against
RecurringTask.pluck(:key) also returns no key.
As a result, neither method schedules the replacement nor cancels the old in-memory Concurrent::ScheduledTask.
Relevant source:
The README explicitly recommends this sequence under “Scheduling and unscheduling recurring tasks dynamically”:
https://github.com/rails/solid_queue#scheduling-and-unscheduling-recurring-tasks-dynamically
Possible fix
Reconcile changed dynamic task definitions as well as created/deleted keys. For example, retain the task definition or a stable fingerprint/version/updated_at alongside each scheduled task and cancel/recreate the scheduled task when its persisted attributes change.
Summary
The documented way to update a dynamic recurring task is to unschedule it and then schedule it again with the same key and updated options:
However, if the deletion and recreation both happen before the scheduler's next dynamic-task poll, the scheduler does not pick up the new schedule. It continues using the old in-memory task definition.
This also occurs if both operations are wrapped in a single database transaction, because the scheduler can never observe the row as absent.
Environment
config/queue.yml:Reproduction
Start a scheduler with dynamic tasks enabled and a short polling interval.
Schedule a task with a schedule that runs frequently:
After the scheduler has picked up the task, immediately replace it using the documented API:
Ensure both calls complete before the next
polling_intervalelapses.Actual behavior
The scheduler continues to run the original
every secondschedule. The replacement task record is present insolid_queue_recurring_taskswithschedule: "every minute", but its updated schedule is not used until the scheduler restarts.Expected behavior
Using the documented unschedule-and-reschedule sequence should replace the active dynamic task definition, even when both database operations occur between scheduler polls.
Alternatively, if this timing constraint is intentional, the documentation should explicitly require waiting until the scheduler observes the deletion before recreating the task with the same key.
Why this happens
Scheduler::RecurringSchedule#reschedule_dynamic_tasksreloads dynamic tasks, then performs only key-based reconciliation:When the row is deleted and recreated with the same key between polls:
scheduled_tasksstill contains"dynamic_task"from the old definition."dynamic_task"from the new definition.where.not(key: scheduled_tasks.keys)returns no row.RecurringTask.pluck(:key)also returns no key.As a result, neither method schedules the replacement nor cancels the old in-memory
Concurrent::ScheduledTask.Relevant source:
lib/solid_queue/scheduler/recurring_schedule.rbhttps://github.com/rails/solid_queue/blob/main/lib/solid_queue/scheduler/recurring_schedule.rb
lib/solid_queue/scheduler.rbhttps://github.com/rails/solid_queue/blob/main/lib/solid_queue/scheduler.rb
The README explicitly recommends this sequence under “Scheduling and unscheduling recurring tasks dynamically”:
https://github.com/rails/solid_queue#scheduling-and-unscheduling-recurring-tasks-dynamically
Possible fix
Reconcile changed dynamic task definitions as well as created/deleted keys. For example, retain the task definition or a stable fingerprint/version/updated_at alongside each scheduled task and cancel/recreate the scheduled task when its persisted attributes change.