correct config to avoid failed report timeouts?

[MattAppleton]

Hi there

We have a cronjob that makes a lab report each day.

0 6 * * * cd apps/urban-mind-berlin && php craft labreports/reports/build --reportId=43248; php craft labreports/reports/build --reportId=47118

The database is getting bigger, and recently we seem to be getting this sort of failure:

The process "'/opt/sp/php8.1/bin/php' 'apps/urban-mind-berlin/craft' 'queue/exec' '322653' '300' '1' '3756896' '--color='" exceeded the timeout of 300 seconds.

The server itself has plenty of overhead, PHP execution is set to 800 for instance, just wondering where / what config we can tune to avoid this timeout?

thanks!

[benjaminkohl]

Hi, Matt. I think this example that makes modifications to your config/app.php file might be what you're looking for: https://servd.host/docs/increasing-crafts-queue-ttr#via-your-config-app-php

Even if your ini file is set to 800, Craft overrides that with 300 by default. I think that is what the second command line parameter is after the '322653' parameter.

[MattAppleton]

@benjaminkohl — thanks for looking at this...

So far no joy. Both the cron job and Craft admin-triggered lab reports seem to fail with the 300 sec ttr warning. For config/app.php we have tried

return [
 'components' => [
 'queue' => [
 'ttr' => 600
 ],
 ],
];

and (via @khalwat)

return [
    'components' => [
        'queue' => [
            'class' => craft\queue\Queue::class,
            'ttr' => 10 * 60,
        ],
    ],
];

neither of these seem to make any difference when running the job by hitting 'run report' in the admin... this is an 'advanced' report by the way... it dies after 300secs.

[benjaminkohl]

Is it possible the php binary running on the command line is not using the ini file that you think it is? I know that can be an issue in some setups. Otherwise, I can't think of what else to check that would be capping the process to 300 seconds.

[MattAppleton]

This config/app.php setup seems to have cracked it — advice from Craft Support:

"The issue is your config/app.php file has two return statements in it, so the 2nd one never gets hit (see attachment).

Something like this should work:

return [
    'id' => App::env('CRAFT_APP_ID') ?: 'CraftCMS',
    'modules' => [
        'my-module' => \modules\Module::class,
    ],
    //'bootstrap' => ['my-module'],
    'components' => [
        'queue' => [
            'class' => craft\queue\Queue::class,
            'ttr' => 15 * 60,
        ],
    ],
];

Worth mentioning that the TTR for a job is embedded along with the job data. So if you have an existing job in the queue that was added with a 300 second TTR and it fails, then retrying that same job will still use the 300 second TTR even if you change config/app.php to use something higher. New jobs added to the queue after the change will have the higher TTR.