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 😄

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

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"} []

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$

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

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

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 https://github.com/Guikingone/SchedulerBundle/issues/93#issuecomment-835801076

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?

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 😢

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

I'm following the quick start guide, and it runs successfully

symfony console scheduler:list


 [OK] 1 task found


+-------------+------+---------------------------+-------------+---------------------+---------------------------+-------------------------+-----------------------------+---------+------+
| Type        | Name | Description               | Expression  | Last execution date | Next execution date       | Last execution duration | Last execution memory usage | State   | Tags |
+-------------+------+---------------------------+-------------+---------------------+---------------------------+-------------------------+-----------------------------+---------+------+
| CommandTask | foo  | A simple cache clear task | */5 * * * * | Not executed        | 2022-10-19T11:40:00+00:00 | Not tracked             | Not tracked                 | enabled |      |
+-------------+------+---------------------------+-------------+---------------------+---------------------------+-------------------------+-----------------------------+---------+------+

Then I installed the debug pack

composer require --dev debug

Once installed, I try again the list command it returned the error

symfony console scheduler:list

In Connection.php line 170:

  The datetime normalizer is not an instance of Symfony\Component\Serializer\Normalizer\DateTimeNormalizer.


In TaskNormalizer.php line 82:

  The datetime normalizer is not an instance of Symfony\Component\Serializer\Normalizer\DateTimeNormalizer.

Then I try to remove all Debug pack dependencies

composer remove symfony/debug-bundle symfony/web-profiler-bundle symfony/monolog-bundle

And then run back the list command, and it works again

symfony console scheduler:list


 [OK] 1 task found


+-------------+------+---------------------------+-------------+---------------------+---------------------------+-------------------------+-----------------------------+---------+------+
| Type        | Name | Description               | Expression  | Last execution date | Next execution date       | Last execution duration | Last execution memory usage | State   | Tags |
+-------------+------+---------------------------+-------------+---------------------+---------------------------+-------------------------+-----------------------------+---------+------+
| CommandTask | foo  | A simple cache clear task | */5 * * * * | Not executed        | 2022-10-19T11:40:00+00:00 | Not tracked             | Not tracked                 | enabled |      |
+-------------+------+---------------------------+-------------+---------------------+---------------------------+-------------------------+-----------------------------+---------+------+

Hello there!

My name is Ana. I noted that you use the mutation testing tool infection in the project. I am a postdoctoral researcher at the University of Seville (Spain), and my colleagues and I are studying how mutation testing tools are used in practice. With this aim in mind, we have analysed over 3,500 public GitHub repositories using mutation testing tools, including yours! This work has recently been published in a journal paper available at https://link.springer.com/content/pdf/10.1007/s10664-022-10177-8.pdf.

To complete this study, we are asking for your help to understand better how mutation testing is used in practice, please! We would be extremely grateful if you could contribute to this study by answering a brief survey of 21 simple questions (no more than 6 minutes). This is the link to the questionnaire https://forms.gle/FvXNrimWAsJYC1zB9.

Drop me an e-mail if you have any questions or comments ([email protected]). Thank you very much in advance!!

| Q | A | ---------------- | --- | PHP version? | >= 8.0 | Bundle version? | 0.11.0 | Symfony version? | >= 5.4 | New feature? | yes | Bug fix? | no | Discussion? | # ...

| Q | A | ---------------- | --- | PHP version? | >= 8.0 | Bundle version? | 0.10.2 | Symfony version? | >= 5.4 | New feature? | no | Bug fix? | yes | Discussion? | # ...

Situation

Testing with my own setup as described in Issue 295, the newly added scheduler:stop-worker command does not seem to have any effect on actually stopping the worker when the scheduler:consume command is being run with the --wait and --force arguments.

Version: 0.10.0

| Q | A | ---------------- | --- | PHP version? | X.X | Bundle version? | X.X.X | Symfony version? | X.X.X | New feature? | yes/no | Bug fix? | yes/no | Discussion? | # ...

| Q | A | ---------------- | --- | PHP version? | >= 8.0 | Bundle version? | 0.10.0 | Symfony version? | >= 5.4 | New feature? | no | Bug fix? | yes | Discussion? | # ...