guikingone/schedulerbundle

Repetitive tasks as a breath in Symfony

Daily runs

Code style	Infection	PHPUnit	Rector	Security	Static analysis

A Symfony bundle built to schedule/consume repetitive tasks

Main features

• External transports (Doctrine, Redis, etc)
• External configuration storage (Doctrine, Redis, etc)
• Retry / Remove / Sort policies
• Background worker
• Symfony/Messenger integration
• Mercure integration
• Fibers support

Installation

Make sure Composer is installed globally, as explained in the installation chapter of the Composer documentation.

composer require guikingone/scheduler-bundle

Quick start

If symfony/flex is not installed, manually update the config/bundles.php:

// config/bundles.php

return [
    // ...
    SchedulerBundle\SchedulerBundle::class => ['all' => true],
];

Then configure a transport in config/packages/scheduler.yaml:

# config/packages/scheduler.yaml
scheduler_bundle:
    transport:
        dsn: 'filesystem://first_in_first_out'

Finally, it's time to create a simple task:

# config/packages/scheduler.yaml
scheduler_bundle:
    transport:
        dsn: 'filesystem://first_in_first_out'
    tasks:
        foo:
            type: 'command'
            command: 'cache:clear'
            expression: '*/5 * * * *'
            description: 'A simple cache clear task'
            options:
                env: test

When a task is configured, time to execute it, two approaches can be used:

• Adding a cron entry * * * * * cd /path-to-your-project && php bin/console scheduler:consume >> /dev/null 2>&1
• Launching the command scheduler:consume --wait in a background command

Documentation

• Usage
• Configuration
• Best practices
• Tasks
• Transports
• Lock
• Commands
• Events
• Lazy Loading
• Messenger
• HTTP entrypoint
• ExecutionPolicies
• SchedulePolicies
• Runners
• Worker
• Scheduler
• Middleware
• Probe
• Tests
• Mercure

Contributing

Want to improve this bundle?

schedulerbundle's Issues

bug(task): ChainedTask no longer works

the execution of the subtasks no longer works.

with the following configuration, only the bar task seems to run.

scheduler_bundle:
  transport:
    dsn: 'doctrine://default?execution_mode=first_in_first_out'
  tasks:
    chained:
      type: 'chained'
      output: true
      description: 'chained with 2 tasks'
      tasks:
        foo:
          type: 'command'
          command: 'app:foo'
          description: 'command foo chained'
          output: true
        bar:
          type: 'command'
          command: 'app:bar'
          description: 'command bar in chained'
          output: true
    task5:
      type: 'command'
      command: 'app:foo'
      description: 'command task 5'
      output: false
    task6:
      type: 'command'
      command: 'app:bar'
      description: 'command task 6'
      output: false

feat(task): handle "deploy" tasks

Task update ROLLBACK

I configured a cron every minute like this * * * * * developer /var/www/app/bin/console scheduler:consume

I defined a single_run chainedTask to run related commands.

In the logs I have ROLLBACK on the update of the task while it is in progress by a previous cron call.
Could the execution of a scheduler:consume on tasks in progress have an impact ?

below the logs I have on the rollback

[2021-04-30T17:15:01.506813+00:00] doctrine.DEBUG: SELECT COUNT(DISTINCT t.id) FROM scheduler_tasks t WHERE t.task_name = :name LOCK IN SHARE MODE {":name":"deploy"} []
[2021-04-30T17:15:01.511597+00:00] app.INFO: A task has been scheduled {"task":"deploy"} []
[2021-04-30T17:15:01.513026+00:00] doctrine.DEBUG: SELECT COUNT(DISTINCT t.id) FROM scheduler_tasks t WHERE t.task_name = :name LOCK IN SHARE MODE {":name":"import_etablissements"} []
[2021-04-30T17:15:01.513958+00:00] app.INFO: A task has been scheduled {"task":"import_etablissements"} []
[2021-04-30T17:15:01.514673+00:00] doctrine.DEBUG: SELECT COUNT(DISTINCT t.id) FROM scheduler_tasks t WHERE t.task_name = :name LOCK IN SHARE MODE {":name":"import_communes"} []
[2021-04-30T17:15:01.515441+00:00] app.INFO: A task has been scheduled {"task":"import_communes"} []
[2021-04-30T17:15:01.516140+00:00] doctrine.DEBUG: SELECT COUNT(DISTINCT t.id) FROM scheduler_tasks t WHERE t.task_name = :name LOCK IN SHARE MODE {":name":"import_eleves"} []
[2021-04-30T17:15:01.516914+00:00] app.INFO: A task has been scheduled {"task":"import_eleves"} []
[2021-04-30T17:15:01.517692+00:00] doctrine.DEBUG: SELECT COUNT(DISTINCT t.id) FROM scheduler_tasks t WHERE t.task_name = :name LOCK IN SHARE MODE {":name":"import_personnels"} []
[2021-04-30T17:15:01.518456+00:00] app.INFO: A task has been scheduled {"task":"import_personnels"} []
[2021-04-30T17:15:01.523958+00:00] doctrine.DEBUG: SELECT COUNT(DISTINCT t.id) FROM scheduler_tasks t LOCK IN SHARE MODE [] []
[2021-04-30T17:15:01.524758+00:00] doctrine.DEBUG: "START TRANSACTION" [] []
[2021-04-30T17:15:01.525727+00:00] doctrine.DEBUG: SELECT t.* FROM scheduler_tasks t ORDER BY task_name ASC [] []
[2021-04-30T17:15:01.576799+00:00] doctrine.DEBUG: "COMMIT" [] []
[2021-04-30T17:15:01.583190+00:00] app.INFO: The worker has been started {"failedTasks":0,"lastExecutedTask":null} []
[2021-04-30T17:15:01.584053+00:00] doctrine.DEBUG: SELECT COUNT(DISTINCT t.id) FROM scheduler_tasks t LOCK IN SHARE MODE [] []
[2021-04-30T17:15:01.584893+00:00] doctrine.DEBUG: "START TRANSACTION" [] []
[2021-04-30T17:15:01.585379+00:00] doctrine.DEBUG: SELECT t.* FROM scheduler_tasks t ORDER BY task_name ASC [] []
[2021-04-30T17:15:01.623175+00:00] doctrine.DEBUG: "COMMIT" [] []
[2021-04-30T17:15:01.631363+00:00] app.INFO: The worker is currently running {"failedTasks":0,"lastExecutedTask":null,"idle":false} []
[2021-04-30T17:15:01.655304+00:00] doctrine.DEBUG: "START TRANSACTION" [] []
[2021-04-30T17:15:01.674965+00:00] doctrine.DEBUG: UPDATE scheduler_tasks SET body = :body WHERE task_name = :name {":name":"deploy",":body":"{\"body\":{\"tasks\":[{\"body\": [...]"} []
[2021-04-30T17:15:01.682368+00:00] doctrine.DEBUG: "ROLLBACK" [] []
[2021-04-30T17:15:01.683534+00:00] doctrine.DEBUG: "START TRANSACTION" [] []
[2021-04-30T17:15:01.688333+00:00] doctrine.DEBUG: UPDATE scheduler_tasks SET body = :body WHERE task_name = :name {":name":"deploy",":body":"{\"body\":{\"tasks\":[{\"body\": [...]"} []
[2021-04-30T17:15:01.690061+00:00] doctrine.DEBUG: "ROLLBACK" [] []
[2021-04-30T17:15:01.691203+00:00] app.INFO: A task execution has failed {"task":"deploy"} []
[2021-04-30T17:15:01.695355+00:00] app.INFO: The worker is currently running {"failedTasks":1,"lastExecutedTask":"deploy","idle":true} []
[2021-04-30T17:15:01.695964+00:00] app.INFO: The worker has been stopped {"failedTasks":1,"lastExecutedTask":"deploy"} []

bug(runner): Unable to find MessengerTaskRunner in Worker

Hi @Guikingone,

When i run scheduler:consume -w it can't launch my MessengerTask.

After some research and with add dump in Worker.php file i recover 6 TaskRunner (Shell, Command, Callback, Notification, Null and Chained) but not the MessengerTaskRunner and HttpTaskRunner.

You can reproduce it with : dd(array_map(function ($runner){return get_class($runner);}, $this->getRunners())); at line 80 in Worker.php file.

It returns :

^ array:6 [
  0 => "SchedulerBundle\Runner\ShellTaskRunner"
  1 => "SchedulerBundle\Runner\CommandTaskRunner"
  2 => "SchedulerBundle\Runner\CallbackTaskRunner"
  3 => "SchedulerBundle\Runner\NotificationTaskRunner"
  4 => "SchedulerBundle\Runner\NullTaskRunner"
  5 => "SchedulerBundle\Runner\ChainedTaskRunner"
]

Is it normal ?

Thanks,

bug(bridge): [MySQL] update() without change throw an exception

The rowCount on a MySQL update without change returns 0 which triggers a false positive on the update.

SchedulerBundle/src/Bridge/Doctrine/Transport/Connection.php

Line 214 in 6dc24eb

if (1 !== $statement->rowCount()) {

build(composer): Symfony 6.0 support

DoctrineTransport table_name configuration

The configuration of the table name (table_name) for the Doctrine transport as described in the document does not work, a camelCase notation is expected in the DoctrineTransportFactory L39
by modifying the option in camelCase notation the name of the table is taken into account.

(Documentation): filesystem transport default path

In the filesystem transport documentation it says that the default path is: %kernel.project_dir%/var/tasks or in the FilesystemTransportFactory it is set by default to sys_get_temp_dir()

SchedulerBundle/src/Transport/FilesystemTransportFactory.php

Line 22 in 866e6c8

return new FilesystemTransport($dsn->getOption('path', sys_get_temp_dir()), [

refactor(command): wrong date displayed

When using scheduler:consume twice within the same minute, the next "execution allowed" date display the current minute, not the next one.

Lock store configuration improvement

Would it be possible to configure the default lock_store with the framework.lock: '%env(LOCK_DSN)%' configuration
instead of having to redefine it ?

in addition the following lock_store configuration: lock_store:'%env(LOCK_DSN)%' does not work, you must pass it a service name.

scheduler_bundle:
  lock_store: lock.default

bug(sort): BatchPolicy

what is this array_walk for ?

SchedulerBundle/src/SchedulePolicy/BatchPolicy.php

Lines 21 to 24 in 0efd88b

	array_walk($tasks, function (TaskInterface $task): void {
	$priority = $task->getPriority();
	$task->setPriority(--$priority);
	});

Think there is an issue ...
what happens if we set a priority to -1000
it will not pass the validation during the setPriorty(--$priority) !

the dump-reference command fails

impossible to dump configuration reference because the file does not respect the naming convention expected by the Extension::getConfiguration() command.

https://symfony.com/doc/current/bundles/configuration.html#dump-the-configuration

possible resolutions
name the file as expected or override the Extension::getConfiguration() command

bug ( Notice: Undefined index: transport ) - configuring guikingone/scheduler-bundle

Hello,

I have a little problem during the installation of the bundle.
I get an error in

Using version ^0.4.0 for guikingone/scheduler-bundle
./composer.json has been updated
Running composer update guikingone/scheduler-bundle
Loading composer repositories with package information
Updating dependencies
Lock file operations: 3 installs, 0 updates, 0 removals
  - Locking dragonmantank/cron-expression (v3.1.0)
  - Locking guikingone/scheduler-bundle (0.4.0)
  - Locking symfony/lock (v5.2.6)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 3 installs, 0 updates, 0 removals
  - Installing symfony/lock (v5.2.6): Extracting archive
  - Installing dragonmantank/cron-expression (v3.1.0): Extracting archive
  - Installing guikingone/scheduler-bundle (0.4.0): Extracting archive
Generating autoload files
composer/package-versions-deprecated: Generating version class...
composer/package-versions-deprecated: ...done generating version class
101 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Endroid Installer detected project type "symfony"

Symfony operations: 2 recipes (ddf663939bb7c4e416e77206b09ab2a6)
  - Configuring symfony/lock (>=5.2): From github.com/symfony/recipes:master
  - Configuring guikingone/scheduler-bundle (>=0.4.0): From auto-generated recipe
Synchronizing package.json with PHP packages
Don't forget to run npm install --force or yarn install --force to refresh your JavaScript dependencies!
Executing script cache:clear [KO]
 [KO]
Script cache:clear returned with error code 1
!!  
!!  In SchedulerBundleExtension.php line 228:
!!                                        
!!    Notice: Undefined index: transport  
!!                                        
!!  
!!  
Script @auto-scripts was called via post-update-cmd

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Where does this problem come from?

feat(command): add a command for crontab file generation

feat(command): add a command to execute tasks depending on tags, name, expression, etc

Related to #60

feat(core): notification on slow tasks

Too few arguments to function SchedulerBundle\Transport\FailOverTransportFactory::__construct()

Hello,

when using failover or doctrine/dbal as transport dsn the following error is thrown:
Too few arguments to function SchedulerBundle\Transport\FailOverTransportFactory::__construct(), 0 passed in [...]/var/cache/dev/ContainerXePqEvI/App_KernelDevDebugContainer.php on line 1071 and exactly 1 expected

Example scheduler.yaml:

scheduler_bundle:
    transport:
        dsn: 'failover://(filesystem://first_in_first_out || memory://first_in_first_out)'
    tasks:
        foo:
            type: 'command'
            command: 'cache:clear'
            expression: '*/5 * * * *'
            description: 'A simple cache clear task'

I'm using guikingone/scheduler-bundle 0.3.1, PHP 7.4 and Symfony 5.2.4.

Is this a known error or am I doing something wrong?

Kind regards,
Marcel

bug(worker): pausing task execution using signal

As explained by @jvancoillie

Hello @Guikingone,
The shutdown works correctly when the worker has gone to sleep but it is impossible for me to stop it when a task is running :(
see the screenshot below, when ctrl-c on the first task, it stops. then the second task the ctrl-c seems to have no effect.

I wonder about quitting a task in progress. we can see that the tasks have been updated and are considered executed that may be problematic in the case of a single_run it considers that the task as fully executed while I forced the stop and it will never replayed 😢

Originally posted by @jvancoillie in #173 (comment)

bug(worker): lost `isFork` option in ChainedTaskRunner

Unless I'm mistaken, when the Worker is cloned into the ChainedTaskRunner the isFork option

SchedulerBundle/src/Worker/AbstractWorker.php

Line 91 in eba50a9

$fork->options['isFork'] = true;

is overwritten at runtime,

SchedulerBundle/src/Runner/ChainedTaskRunner.php

Lines 31 to 33 in eba50a9

	$task->getTasks()->walk(function (TaskInterface $task) use ($forkedWorker): void {
	$forkedWorker->execute([], $task);
	});

so we are no longer able to determine that this Worker is a fork.

---

Another point, how can we from an WorkerRunningEventListener of the forked Worker stop the copied Worker (in other words the parent worker in the case of ChainedTaskRunner)?

config(dsn): allow to use env variable

refactor(schedulepolicy): DeadlinePolicy logic

Improve the DeadlinePolicy to fully respect the man page:

SCHED_DEADLINE: Sporadic task model deadline scheduling
       Since version 3.14, Linux provides a deadline scheduling policy
       (SCHED_DEADLINE).  This policy is currently implemented using
       GEDF (Global Earliest Deadline First) in conjunction with CBS
       (Constant Bandwidth Server).  To set and fetch this policy and
       associated attributes, one must use the Linux-specific
       sched_setattr(2) and sched_getattr(2) system calls.

       A sporadic task is one that has a sequence of jobs, where each
       job is activated at most once per period.  Each job also has a
       relative deadline, before which it should finish execution, and a
       computation time, which is the CPU time necessary for executing
       the job.  The moment when a task wakes up because a new job has
       to be executed is called the arrival time (also referred to as
       the request time or release time).  The start time is the time at
       which a task starts its execution.  The absolute deadline is thus
       obtained by adding the relative deadline to the arrival time.

       The following diagram clarifies these terms:

           arrival/wakeup                    absolute deadline
                |    start time                    |
                |        |                         |
                v        v                         v
           -----x--------xooooooooooooooooo--------x--------x---
                         |<- comp. time ->|
                |<------- relative deadline ------>|
                |<-------------- period ------------------->|

       When setting a SCHED_DEADLINE policy for a thread using
       sched_setattr(2), one can specify three parameters: Runtime,
       Deadline, and Period.  These parameters do not necessarily
       correspond to the aforementioned terms: usual practice is to set
       Runtime to something bigger than the average computation time (or
       worst-case execution time for hard real-time tasks), Deadline to
       the relative deadline, and Period to the period of the task.
       Thus, for SCHED_DEADLINE scheduling, we have:

           arrival/wakeup                    absolute deadline
                |    start time                    |
                |        |                         |
                v        v                         v
           -----x--------xooooooooooooooooo--------x--------x---
                         |<-- Runtime ------->|
                |<----------- Deadline ----------->|
                |<-------------- Period ------------------->|

       The three deadline-scheduling parameters correspond to the
       sched_runtime, sched_deadline, and sched_period fields of the
       sched_attr structure; see sched_setattr(2).  These fields express
       values in nanoseconds.  If sched_period is specified as 0, then
       it is made the same as sched_deadline.

       The kernel requires that:

           sched_runtime <= sched_deadline <= sched_period

       In addition, under the current implementation, all of the
       parameter values must be at least 1024 (i.e., just over one
       microsecond, which is the resolution of the implementation), and
       less than 2^63.  If any of these checks fails, sched_setattr(2)
       fails with the error EINVAL.

       The CBS guarantees non-interference between tasks, by throttling
       threads that attempt to over-run their specified Runtime.

       To ensure deadline scheduling guarantees, the kernel must prevent
       situations where the set of SCHED_DEADLINE threads is not
       feasible (schedulable) within the given constraints.  The kernel
       thus performs an admittance test when setting or changing
       SCHED_DEADLINE policy and attributes.  This admission test
       calculates whether the change is feasible; if it is not,
       sched_setattr(2) fails with the error EBUSY.

       For example, it is required (but not necessarily sufficient) for
       the total utilization to be less than or equal to the total
       number of CPUs available, where, since each thread can maximally
       run for Runtime per Period, that thread's utilization is its
       Runtime divided by its Period.

       In order to fulfill the guarantees that are made when a thread is
       admitted to the SCHED_DEADLINE policy, SCHED_DEADLINE threads are
       the highest priority (user controllable) threads in the system;
       if any SCHED_DEADLINE thread is runnable, it will preempt any
       thread scheduled under one of the other policies.

       A call to fork(2) by a thread scheduled under the SCHED_DEADLINE
       policy fails with the error EAGAIN, unless the thread has its
       reset-on-fork flag set (see below).

       A SCHED_DEADLINE thread that calls sched_yield(2) will yield the
       current job and wait for a new period to begin.

Source: https://man7.org/linux/man-pages/man7/sched.7.html

build(php): Drop 7.4 support

Why ?

• Symfony 6 will requires PHP 8.0 by default
• Because 8.0 rocks 🚀

Planned version: 0.*.0

As 7.4 support will stop (except security one) at 28 Nov 2021, it could be a good idea to stop supporting it at the same time, this way, we can support Symfony 6.0 at the same time without launching tests on unsupported version.

bug(bridge): Doctrine::update()

Hi,

Task update fails due to lock mode (getWriteLockSQL()) which I think is only available on a SQL SELECT command.

that throws the following exception

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'FOR UPDATE' at line 1

FIFO sort

Seems that #75 doesn't fix the FIFO sort 😢

scheduler_bundle:
  transport:
    dsn: 'doctrine://default?execution_mode=first_in_first_out'
  tasks:
    foo:
      type: 'command'
      command: 'app:foo'
      description: 'foo placeholder task'
      output: true
      single_run: true
    bar:
      type: 'command'
      command: 'app:bar'
      description: 'foo placeholder task'
      output: true
      single_run: true

expected foo then bar right ?

feat(scheduler): support for preemption

Source: https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html

bug(bridge): Doctrine::setup()

Hello again ;-)

It seems like the auto_setup of the doctrine transport is not being executed. I used this as dsn in the scheduler.yaml.
dsn: 'doctrine://default?execution_mode=first_in_first_out&table_name=scheduler&auto_setup=true'

It looks like the Connection->create function of the doctrine connection class is always called first and this supposes, that the used database table already exists. But the setup() function will only be called in the executeQuery method.
The following error message is being displayed:

  An exception occurred while executing 'SELECT COUNT(t.id) as task_count FROM _symfony_scheduler_tasks t WHERE t.task_name = ? LOCK IN SHARE MODE' with params ["send-pending-messages"]:

  SQLSTATE[42S02]: Base table or view not found: 1146 Table 'bgr_web_dev._symfony_scheduler_tasks' doesn't exist

However I managed to call the setup function manually and the table _symfony_scheduler_tasks has been created with the columns id, task_name and body. Now when running php bin/console scheduler:consume I'm getting the following error:

 An exception occurred while executing 'INSERT INTO _symfony_scheduler_tasks (task_name, body) VALUES(?, ?) FOR UPDATE' with params ["send-pending-messages", "{\"body\":......"}"]:

  SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FOR UPDATE' at line 1

I guess INSERT INTO ... FOR UPDATE ... is not a valid statement, right?

Kind regards,
Marcel

bug(command): scheduler:execute shortcut "n" already exists

The execution of the command does not work an error is thrown

an option with shortcut "n" already exists.

this is the default --no-interactionshortcut option.

bug(transport) FilesystemTransport - FIFO sort test failed

If FIFO sort does not work on your PR, be sure to have rebased against main, if the issue still occurs, consider opening a new PR 🙂

my branch is up to date with upstream, the testTaskListCanBeRetrieved failed.

1) Tests\SchedulerBundle\Transport\FilesystemTransportTest::testTaskListCanBeRetrieved
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'foo'
+'bar'

Originally posted by @Guikingone in #93 (comment)

feat(worker): Parallel execution

Currently it seems like all scheduled jobs are executed sequentially.
Would it be possible to leverage the messenger system somehow so that each job (or a defined number of jobs) can run in parallel?

WARNING: The task "..." cannot be created as an existing one has been found

Hi there, it's me again :-)

I finally tested the doctrine transport with release version 0.4.1. Everything seems to work fine so far. A new table has been created successfully by using auto_setup=true. Thank you very much :-)

One little thing: With every run of scheduler:consume the following warning is being logged for each task:
WARNING: The task "..." cannot be created as an existing one has been found
The warning is being logged in the Connection.php create($task) function. I guess this isn't the intended behavior, right?

Best regards
Marcel

Unable to create a MessengerTask

Hello,

I want to create a MessengerTask in order to create task and register it on your scheduler, and your scheduler tell to messenger "disptach this message".

$task = (new MessengerTask(uniqid(), new FooSchedulerMessage("My message")))
	->setExpression(
		$fluentExpression
			->build($expression, 'Europe/Paris')
			->getExpression()
	)
	->setTimezone(new \DateTimeZone('Europe/Paris'))
	->setSingleRun(true)
;
$scheduler->schedule($task);

scheduler_bundle:
    transport:
        dsn: 'doctrine://default?execution_mode=first_in_first_out&table_name=scheduler_tasks'

With this code I've got an error :

Argument 2 passed to SchedulerBundle\Serializer\TaskNormalizer::SchedulerBundle\Serializer\{closure}() must be an instance of SchedulerBundle\Task\MessengerTask, instance of App\Message\FooSchedulerMessage given, called in /var/www/html/vendor/symfony/serializer/Normalizer/AbstractObjectNormalizer.php on line 188

My stack:

• Symfony: 5.2.2
• PHP FPM: 7.4
• Scheduler Bundle: 0.4.1
• Symfony Messenger: 5.2.5

---

The crash is located here :

SchedulerBundle/src/Serializer/TaskNormalizer.php

Lines 120 to 123 in d5756a0

	'message' => fn ($innerObject, MessengerTask $outerObject, string $attributeName, string $format = null, array $context = []): array => [
	'class' => get_class($innerObject),
	'payload' => $this->objectNormalizer->normalize($innerObject, $format, $context),
	],

You test a serializer but it's not a normalizer instead ?

SchedulerBundle/tests/Serializer/TaskNormalizerTest.php

Lines 413 to 428 in d5756a0

	public function testMessengerTaskCanBeDenormalized(): void
	{
	$objectNormalizer = new ObjectNormalizer(null, null, null, new PropertyInfoExtractor([], [new PhpDocExtractor(), new ReflectionExtractor()]));
	$notificationTaskBagNormalizer = new NotificationTaskBagNormalizer($objectNormalizer);
	$serializer = new Serializer([$notificationTaskBagNormalizer, new TaskNormalizer(new DateTimeNormalizer(), new DateTimeZoneNormalizer(), new DateIntervalNormalizer(), $objectNormalizer, $notificationTaskBagNormalizer), new DateTimeNormalizer(), new DateIntervalNormalizer(), new JsonSerializableNormalizer(), $objectNormalizer], [new JsonEncoder()]);
	$objectNormalizer->setSerializer($serializer);
	$data = $serializer->serialize(new MessengerTask('foo', new FooMessage()), 'json');
	$task = $serializer->deserialize($data, TaskInterface::class, 'json');
	self::assertInstanceOf(MessengerTask::class, $task);
	self::assertSame('foo', $task->getName());
	self::assertInstanceOf(FooMessage::class, $task->getMessage());
	self::assertSame('* * * * *', $task->getExpression());
	}

Thanks

bug(0.4.7): scheduler due tasks error

Configuration:

scheduler_bundle:
     transport:
         dsn: 'cache://app'
     tasks:
         tv_update:
             type: 'command'
             command: 'tv:update'
             expression: '0 */8 * * *'
             description: 'Tv Update'

Sample project without any launched tasks ever

0.4.7

www-data@b717c3983f1d:~/html$ bin/console scheduler:consume -vvv

In Scheduler.php line 151:
                                              
  [Error]                                     
  Call to a member function format() on null  
                                              

Exception trace:
  at /var/www/html/vendor/guikingone/scheduler-bundle/src/Scheduler.php:151
 SchedulerBundle\Scheduler->SchedulerBundle\{closure}() at n/a:n/a
 array_filter() at /var/www/html/vendor/guikingone/scheduler-bundle/src/Task/TaskList.php:92
 SchedulerBundle\Task\TaskList->filter() at /var/www/html/vendor/guikingone/scheduler-bundle/src/Scheduler.php:151
 SchedulerBundle\Scheduler->getDueTasks() at /var/www/html/vendor/guikingone/scheduler-bundle/src/Command/ConsumeTasksCommand.php:101
 SchedulerBundle\Command\ConsumeTasksCommand->execute() at /var/www/html/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /var/www/html/vendor/symfony/console/Application.php:989
 Symfony\Component\Console\Application->doRunCommand() at /var/www/html/vendor/symfony/framework-bundle/Console/Application.php:96
 Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at /var/www/html/vendor/symfony/console/Application.php:290
 Symfony\Component\Console\Application->doRun() at /var/www/html/vendor/symfony/framework-bundle/Console/Application.php:82
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /var/www/html/vendor/symfony/console/Application.php:166
 Symfony\Component\Console\Application->run() at /var/www/html/bin/console:42

scheduler:consume [-l|--limit LIMIT] [-t|--time-limit TIME-LIMIT] [-f|--failure-limit FAILURE-LIMIT] [-w|--wait]

0.4.6

www-data@b717c3983f1d:~/html$ bin/console scheduler:consume -vvv

 [WARNING] No due tasks found                                                                                           
                           

Sample project with a task which was launched before

The task is launched every time.

bug(command): scheduler:consume --wait no longer works

Hi @Guikingone,

When I run the scheduler in --wait mode it gives me back control and no longer waits every minute

developer@0461266b29f1:/var/www/app$ bin/console scheduler:consume --wait -vv

 ! [NOTE] The worker will wait for tasks every minutes

 // Quit the worker with CONTROL-C.

09:48:26 INFO      [app] The worker has been started ["failedTasks" => 0,"lastExecutedTask" => null]
09:48:26 INFO      [app] The worker has been stopped ["failedTasks" => 0,"lastExecutedTask" => null]
developer@0461266b29f1:/var/www/app$

refactor(worker): replace getOptions by getConfiguration

feat(bag): Add support for emails on task lifecycle

tools(rector): CI

feat(core): execution plan

Q	A
PHP version?	7.4
Bundle version?	next (as minor)
New feature?	yes
Bug fix?	no

Context

The idea here is to being able to create an "execution plan" that can executed when required using scheduler:plan:

{
    "scope": "deploy",
    "scheduler": {
        "mode": "lazy",
    },
    "tasks": [],
    # ...
}

This execution plan can be used to handle deployment phase and so on.

DueTask scheduled inconsistent

There is a problem with the recovery and execution of scheduled tasks.

task configuration :

scheduler_bundle:
  transport:
    dsn: 'doctrine://default?execution_mode=first_in_first_out'
  tasks:
    bar:
      type: 'command'
      command: 'debug:router'
      description: 'Display current routes for an application'

See below

when setting up the tasks we can see that the next execution is set 2021-05-09T11:19:00+00:00

I then request a consume, the task is executed and the date of last execution 2021-05-09T11:18:39+00:00 is less than the initial date of execution!

bug(scheduler): returning tasks

As mentioned here, tasks are returned even on non zero seconds calls from the scheduler, we must ensure that tasks are returned only IF the call on Scheduler::getDueTasks() is on valid datetime.

Desired behaviour:

If the current date is 01-01-2021 at 10:00:00, when calling the command scheduler:consume at 01-01-2021 at 10:00:10, the tasks should not be returned.

feat(core): support for custom Runtime

Source: https://symfony.com/doc/current/components/runtime.html#create-your-own-runtime

feat(core): support for Mercure

bug(scheduler): consuming tasks in separate processes

Task is running multiple times.

with the following tasks configuration :

scheduler_bundle:
  transport:
    dsn: 'doctrine://default?execution_mode=first_in_first_out'
  tasks:
    foo:
      type: 'command'
      command: 'app:foo'
      description: '3mins task'
      single_run: true
    bar:
      type: 'command'
      command: 'app:bar'
      description: '1mins task'
      single_run: true

and a cron configuration : * * * * * cd /path-to-your-project && php bin/console scheduler:consume >> /dev/null 2>&1

the first scheduler:consume output :

   [OK] Task "bar" succeed. (Duration: 1 min, Memory used: 28.0 MiB)

one minute later second call scheduler:consume output :

   [OK] Task "foo" succeed. (Duration: 3 mins, Memory used: 27.9 MiB)
   [OK] Task "bar" succeed. (Duration: 1 min, Memory used: 28.0 MiB)

we can see that the bar task is executed twice. How can we ensure the uniqueness of tasks.

I hope to be clear enough in my explanation 😄

feat(task): use attributes to schedule tasks

More info: https://www.php.net/manual/fr/language.attributes.php

symfony cache:clear failed without database

Hi @Guikingone, hope you are doing well 😉

Since the upgrade of the bundle to version 0.5.2 the CI build job no longer work because during the composer install a cache: clear is called and returns the error:

Executing script cache:clear [KO]
 [KO]
Script cache:clear returned with error code 1
!!  
!!   // Clearing the cache for the prod environment with debug                      
!!   // false                                                                       
!!  
!!  14:35:45 CRITICAL  [console] Error thrown while running command "cache:clear". Message: "An exception occurred in driver: SQLSTATE[HY000] [2002] Connection refused" ["exception" => Doctrine\DBAL\Exception\ConnectionException { …},"command" => "cache:clear","message" => "An exception occurred in driver: SQLSTATE[HY000] [2002] Connection refused"]
!!  
!!  In AbstractMySQLDriver.php line 112:
!!                                                                                
!!    An exception occurred in driver: SQLSTATE[HY000] [2002] Connection refused  
!!                                                                                
!!  
!!  In Exception.php line 18:
!!                                               
!!    SQLSTATE[HY000] [2002] Connection refused  
!!                                               
!!  
!!  In PDOConnection.php line 39:
!!                                               
!!    SQLSTATE[HY000] [2002] Connection refused  
!!                                               
!!  
!!  cache:clear [--no-warmup] [--no-optional-warmers]
!!  
!!  
Script @auto-scripts was called via post-install-cmd
make: *** [Makefile:246: vendor/autoload.php] Error 1

I had to downgrade to version 0.4.9 to no longer have the problem 😢

refactor(worker): sub-tasks output

it is not possible to have the output for "sub-tasks" in chained tasks type, are there any plans to improve this ?

Error: Call to a member function format() on null

I guess it happens when the task never run before?

16:18:02 CRITICAL  [console] Error thrown while running command "scheduler:consume -vv". Message: "Call to a member function format() on null" ["exception" => Error { …},"command" => "scheduler:consume -vv","message" => "Call to a member function format() on null"]

In Scheduler.php line 151:
                                              
  [Error]                                     
  Call to a member function format() on null  
                                              

Exception trace:
  at /var/www/subs.leapt.io/vendor/guikingone/scheduler-bundle/src/Scheduler.php:151
 SchedulerBundle\Scheduler->SchedulerBundle\{closure}() at n/a:n/a
 array_filter() at /var/www/subs.leapt.io/vendor/guikingone/scheduler-bundle/src/Task/TaskList.php:92
 SchedulerBundle\Task\TaskList->filter() at /var/www/subs.leapt.io/vendor/guikingone/scheduler-bundle/src/Scheduler.php:151
 SchedulerBundle\Scheduler->getDueTasks() at /var/www/subs.leapt.io/vendor/guikingone/scheduler-bundle/src/Command/ConsumeTasksCommand.php:101
 SchedulerBundle\Command\ConsumeTasksCommand->execute() at /var/www/subs.leapt.io/vendor/symfony/console/Command/Command.php:288
 Symfony\Component\Console\Command\Command->run() at /var/www/subs.leapt.io/vendor/symfony/console/Application.php:992
 Symfony\Component\Console\Application->doRunCommand() at /var/www/subs.leapt.io/vendor/symfony/framework-bundle/Console/Application.php:96
 Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at /var/www/subs.leapt.io/vendor/symfony/console/Application.php:291
 Symfony\Component\Console\Application->doRun() at /var/www/subs.leapt.io/vendor/symfony/framework-bundle/Console/Application.php:82
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /var/www/subs.leapt.io/vendor/symfony/console/Application.php:167
 Symfony\Component\Console\Application->run() at /var/www/subs.leapt.io/vendor/symfony/runtime/Runner/Symfony/ConsoleApplicationRunner.php:56
 Symfony\Component\Runtime\Runner\Symfony\ConsoleApplicationRunner->run() at /var/www/subs.leapt.io/vendor/autoload_runtime.php:35
 require_once() at /var/www/subs.leapt.io/bin/console:11

bug(policies): Tasks not sorted correctly using FIFO

🤔 This is not what I find with the above configuration, I expected to have the world command before the hello command

Originally posted by @jvancoillie in #69 (reply in thread)

bug(command): scheduler:consume --wait cannot be stopped

Source: #159 (comment)

bug(collector): scheduler panel

Hello it's me again,

I throw an exception when I consult the profiler (_profiler/latest?panel=scheduler)

after having consulted the HTTP entrypoint _tasks?name=activation.
maybe it's related to the single_run #45 issue

thank you again for your responsiveness

Doctrine and Redis transport factories are not injected into TransportFactory constructor

Hello,

now with the new version 0.3.2 I'm trying to use the doctrine transport, but somehow the DoctrineTransportFactory and RedisTransportFactory implementations of the interface TransportFactoryInterface are not being injected into the TransportFactory constructor and so the error message I get is No transport supports the given Scheduler DSN "doctrine://..."

All implementations under /src/Transport are injected by the DI system, but the two lying under /src/Bridge/... are not.
Is this a configuration issue on my side?

Kind regards,
Marcel