Skip to content

Dynamic recurring-task reschedule is not detected when the same key is recreated before the next scheduler poll #792

Description

@AmShaegar13

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions