Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How do you 'refresh' your scheduled tasks when you make a change to the scheduler.yaml? #321

Open
mmjr-x opened this issue Jul 26, 2023 · 1 comment
Assignees

Comments

@mmjr-x
Copy link

mmjr-x commented Jul 26, 2023

@Guikingone First of all thank you for your great work and your amazing bundle! :)

We are currently using your bundle however we are running into the issue that whenever we make a change to the scheduler.yaml (in our case specifically changing the expression of a task) that the scheduled task is not updated in our _symfony_scheduler_tasks database table.

We hypothesized that it might be the case that the tasks first has have to been executed and afterwards its configuration is refreshed, however after some testing this also did not seem to be the case.

I tried studying the documentation however however aside from rebooting the scheduler using bin/console scheduler:reboot we found the only way to have it refresh task from the updated configuration of the scheduler.yaml is to delete the database entry for that task. Afterwards it will get readded on the next bin/console scheduler:consume (we run this in a cron every minute).

Sadly we can't use scheduler:reboot since we have both a mix of programmatically scheduled tasks and tasks scheduled via the scheduler.yaml configuration (using scheduler:reboot also removes all programmatically scheduled tasks which cant be easily rescheduled).

First of al I am wondering if what we are seeing is the intended behavior, if this is due to a configuration mistake on our end or perhaps a bug to some extend?

Second I would like to know if there is some workaround, or configuration we can do to either have it update automatically or if there is some way to exclude certain scheduled tasks (in our case the programmatically set up ones) from the scheduler:reboot?

Some additional info about our setup:

  • php 8.1
  • Symfony 6.3
  • guikingone/scheduler-bundle 0.10.*
  • Excempt from our scheduler.yaml (does not include all tasks and some names where changed for privacy reasons):
scheduler_bundle:
  transport:
    dsn: 'doctrine://default?execution_mode=first_in_first_out'
  tasks:
    import_run_x1:
      type: 'command'
      command: 'app:import:run'
      arguments: ['1', '1']
      expression: '0 3 * * *'
      description: 'Runs the type 1 import for x1'
    import_run_x2:
      type: 'command'
      command: 'app:import:run'
      arguments: ['1', '2']
      expression: '0 2 * * *'
      description: 'Runs the type 1 import for x2'

If you could offer any help or advice on this issue it would be much appreciated! :)

@Guikingone
Copy link
Owner

Hi @mmjr-x 👋🏻

Sorry for the delay, thanks for the feedback, regarding the subjects that you're pointing:

We are currently using your bundle however we are running into the issue that whenever we make a change to the scheduler.yaml (in our case specifically changing the expression of a task) that the scheduled task is not updated in our _symfony_scheduler_tasks database table.

We hypothesized that it might be the case that the tasks first has have to been executed and afterwards its configuration is refreshed, however after some testing this also did not seem to be the case.

I tried studying the documentation however however aside from rebooting the scheduler using bin/console scheduler:reboot we found the only way to have it refresh task from the updated configuration of the scheduler.yaml is to delete the database entry for that task. Afterwards it will get readded on the next bin/console scheduler:consume (we run this in a cron every minute).

Hum, that's strange, the tasks should be updated as soon as the cache is cleared, the transport is created during this phase and tasks scheduled once its cleared (see https://github.com/Guikingone/SchedulerBundle/blob/main/src/DependencyInjection/SchedulerBundleExtension.php#L1261), keep in mind that if the issue is triggered in prod env, updating the configuration is not enough, you must clear the cache.

The execution of a task is not tied to its existence in the configuration, as long as the task is "scheduled", the worker will grab it and execute it once the due date is encountered.

Regarding the reboot command, its usage is tied to the fact that you need to "clear" the scheduler, not reschedule tasks, this command is tied to the usage of @reboot expression, not the refresh of the configuration 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants