Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#792 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rails, ruby
Área
backend, databases

Línea de trabajo

Start with lib/solid_queue/scheduler/recurring_schedule.rb and trace how Scheduler invokes reschedule_dynamic_tasks from lib/solid_queue/scheduler.rb. Reproduce with dynamic tasks enabled and a short polling interval, then verify that replacing a task with the same key causes the active schedule to use the new definition without restarting the scheduler.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Ruby
Estrellas
2.5k
Forks
255
Sin PR fusionados en 30 d

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rails/solid_queue

Todos los issues de rails/solid_queue

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.