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

[jvancoillie]

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$

[Guikingone]

Hi @jvancoillie 👋🏻

Hum strange, do you have any scheduled tasks when launching the command?

[Guikingone]

Hi @jvancoillie 👋🏻

I've pushed a first version of a fix via dev-issue/159, could you test it when you have a moment? Thanks 🙂

[Bastien2805]

Hi @Guikingone,

I think i have the same issue so i prefer ask directly here.

When i launch "scheduler:consume -w" i have this :

$ bin/console scheduler:consume -w
                                                                                                                       
 [WARNING] Each tasks has already been executed for the current minute                                                  
                                                                                                                        
 Consider calling this command again at "2021-06-30 04:12"               

After, it just give me back control.

Thanks.

[Guikingone]

Hi @Bastien2805 👋🏻

Yes, it could be related as I'm facing the issue locally, I'm currently in holidays so the PR has stale a little bit 😄

I'm gonna fix it fast, could you test it against dev-issue/159?

[jvancoillie]

Hello @Guikingone 🥇

I just tested the dev/159 and it seems to work.

thanks

[Bastien2805]

Hi @Guikingone,

I also tested it but it still doesn't work for me. I have the same message and it give me back control.

Do you need more specific information to resolve it ?

Thanks.

[Guikingone]

Hi @Bastien2805,

Could you share the scheduler.yaml file?

This way, we can see the transport used along with the tasks 🙂

[Bastien2805]

Hi, here is my scheduler.yaml file.

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

[Guikingone]

Hi @Bastien2805 and @jvancoillie,

I've pushed a small fix (mainly in the worker), could you test it via dev-issue/159?

Thanks and very sorry for this bug 🙁

[Bastien2805]

Hi @Guikingone,

Thanks for the fix but it still doesn't work for me with the same error message and configuration in scheduler.yaml file.

[Guikingone]

Hi @jvancoillie,

Could you validate that if fix your issue when you have a moment?

Thanks 🙂

[jvancoillie]

Hello @Guikingone,

I just tested on dev-issue / 159 with the following configuration :

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

the wait option seems to do its job and maybe a little too much because I no longer have the possibility to quit the worker CTRL + C :(

I also have behavior that IMHO shouldn't be.
When I run the command scheduler:consume --wait a second time it displays the following warning 🤔

shouldn't it be able to resume sleeping mode WDYT ?

[Guikingone]

the wait option seems to do its job and maybe a little too much because I no longer have the possibility to quit the worker CTRL + C

Hum, strange, I'm gonna explore this issue.

When I run the command scheduler:consume --wait a second time it displays the following warning

Yes, this behaviour has been introduced in 0.4.5 and discussed with @Bastien2805, #161 should fix the issue, could you test it?

[jvancoillie]

Yes, this behaviour has been introduced in 0.4.5 and discussed with @Bastien2805, #161 should fix the issue, could you test it?

👍 dev-feat/wait_force no longer display warning with --forceoption but it gives me back control, maybe this is normal because it should not contain the dev-issue/159 fix, right?

[Guikingone]

maybe this is normal because it should not contain the dev-issue/159 fix, right?

dev-issue/159 is not implemented for now, that could be the reason, you're right 🙂

[Guikingone]

Hi @jvancoillie 👋🏻

Could you confirm that dev-issue/159 fix the "control" issue, I'm talking about the command ending process and not the sleep call, if so, could you open a new issue for the sleep call?

Thanks 🙂

[Guikingone]

Hi @jvancoillie 👋🏻

I've moved the sleep call issue to a new issue 🙂

Link: #165