don't push new job for each item if ttr is null

[i-just]

Description

The check to ensure we didn’t hit the TTL was kicking in for every batched job that had the ttr set to null, causing a new job to be added to the queue for each item that needed to be processed.

Example:

• have an install with 2 sites and a section enabled for only one site
• go and enable that section for the second site
• the ResaveElements job gets triggered with ttr set to null (default), and each item it’s supposed to resave is pushed to the queue as a new job

Related issues

n/a

[timkelty]

@i-just this makes sense, but curious where it was happening? In core or a plugin?

• ::: warning
• Batched jobs should always be pushed to the queue using [[QueueHelper::push()]],
• so the priority and ttr settings can be maintained for additional spawned jobs.
• :::

Seems like anywhere pushing a batched job should but using the helper, and thus, shouldn't have a null ttr.

[i-just]

The easiest way to reproduce is to use the steps from my example - that’s as core as it can be, right? In the example I described, the ResaveElements job is triggered from here

It also happens with Feed Me import (that’s how I discovered it).

[i-just]

So they will be maintained if they’re set in the first place, but if they’re not set then they default to null.

[timkelty]

So they will be maintained if they’re set in the first place, but if they’re not set then they default to null.

I think we need to do something like this in init/constructor:

$this->ttr = $this->ttr ?? Craft::$app->getQueue()->ttr;

[i-just]

@timkelty, as per our chat, I pushed a change we agreed on to ensure the ttr is set (even if to a default value)