Delay in date-related Workflows

[githubuser-112]

Hi,

because of problems with our background jobs we checked the steps in your wiki.

In the first step, your processes look a little different. Could you take a look and tell us, if something in our processes could be the cause?

web11    1413383  0.0  0.0  48088  3152 ?        S    14:01   0:00 sh -c '/opt/php-8.2/bin/php' 'artisan' queue:work --queue='emails,default,1da7b20b9daf157d72d52efb2a105583' --sleep=5 --tries=1 --timeout=1800 > '/var/www/clients/client1/web11/web/storage/logs/queue-jobs.log' 2>&1
web11    1413384  0.0  0.1 358460 73028 ?        S    14:01   0:01 /opt/php-8.2/bin/php artisan queue:work --queue=emails,default,1da7b20b9daf157d72d52efb2a105583 --sleep=5 --tries=1 --timeout=1800

Thanks a lot!

PHP version: 8.2.8 FreeScout version: 1.8.8

[freescout-helpdesk]

Your processes list looks fine.

[githubuser-112]

Thanks for checking! We do not know what to do, because everything looks fine, but workflows like this do not fire at exactly 1h but at 1:40, 1:45 or 1:48.

Any other idea what we could look for or do?

[freescout-helpdesk]

We've just double checked - the workflow was triggered after 1 hour and 5 minutes. You'll need to debug Workflows code on your server.

[githubuser-112]

Where do the 5 minutes come from? Isn´t the cron run every minute, so the workflow should work every minute?

Also might the --timeout=1800 in our process keep it from working continuously?

[freescout-helpdesk]

Also might the --timeout=1800 in our process keep it from working continuously?

No, this parameter has another function.

Date-related conditions are checked once an hour, so for different conversation this delay may be different. You can set custom check interval via WORKFLOWS_PROCESS_CRON="0 * * * *" parameter in the .env file and clear cache. Cron schedule can be generated using https://crontab.guru

But don't make date-related workflows to run very often as it may overload your FreeScout. Like for example running them every minute is obvious overkill.

[githubuser-112]

Thanks, that could be it! Adding WORKFLOWS_PROCESS_CRON=0 * * * * (without alteration to test it) to the .env file, results in a server error though:

[error] 86916#86916: *3986350 FastCGI sent in stderr: "PHP message: PHP Warning:  Trying to access array offset on value of type null in /var/www/clients/client1/web11/web/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php on line 159; PHP message: PHP Fatal error:  Uncaught ReflectionException: Class "config" does not exist in /var/www/clients/client1/web11/web/overrides/laravel/framework/src/Illuminate/Container/Container.php:752
Stack trace:
#0 /var/www/clients/client1/web11/web/overrides/laravel/framework/src/Illuminate/Container/Container.php(752): ReflectionClass->__construct()
#1 /var/www/clients/client1/web11/web/overrides/laravel/framework/src/Illuminate/Container/Container.php(631): Illuminate\Container\Container->build()
#2 /var/www/clients/client1/web11/web/overrides/laravel/framework/src/Illuminate/Container/Container.php(586): Illuminate\Container\Container->resolve()
#3 /var/www/clients/client1/web11/web/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(732): Illuminate\Container\Container->make()
#4 /var/www/clients/client1/web11/web/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php(110): Illuminate\Foundation\Application->make()
#5 /var/www/clients/client1/web11/web/vendor/laravel/f" while reading response header from upstream, client: xx.xx.xx.xx, server: domain.name, request: "POST /polycast/receive HTTP/2.0", upstream: "fastcgi://unix:/var/lib/php5-fpm/web11_d6e4337b.sock:", host: "domain.name", referrer: "https://domain./"

[freescout-helpdesk]

Try (don't forget double quotes):

WORKFLOWS_PROCESS_CRON="0 * * * *"

[githubuser-112]

Thanks, this solved our problem we were trying to fix for weeks now!!

It would have been great though if this information was publically available as you told us that we have problems with our background-jobs even though it was only delayed because of this setting (see #3221). With the standard setting every time-related workflow can take up to an hour to be processed after it has met its conditions. This is pretty counter-intuitive, you could mention it in the Workflow-Module information.