Laravel 11: Job thottling. A throttle is a try?

[gldrenthe89]

Hi there,

I am currently building a new application where I need to make connections to third-party APIs. Obviously, I need to throttle the calls to those APIs. I want to do this using a Throttle middleware asdocumented. I have this working, but I found out that each time a job is throttled, it gets a +1 on tries. In my humble opinion, this should not be the case, as the code inside the handle() function itself hasn’t been run yet. This is presenting me with an issue. It is important that these specific jobs only run once, even if they fail. They should not retry on failure. Thus, in my Laravel Horizon settings, I set max tries to 1. As you can predict, every job that is throttled gets an additional try, thus failing on the second attempt.

Any suggestions?

[ghost]

Hi. I use

    public int $tries = 1;

in my jobs and always try catch the code from handle function. If the code fails I log the error and that is it. In that way the laravel logic for failed jobs is bypassed. If I want to create a new job, I dispatch a new one from the catch block.

[gldrenthe89]

Hi. I use

    public int $tries = 1;

in my jobs and always try catch the code from handle function. If the code fails I log the error and that is it. In that way the laravel logic for failed jobs is bypassed. If I want to create a new job, I dispatch a new one from the catch block.

This is not a solution for throttled jobs. If the job is throtled, thus not yet failed it gets a try of 1, it gets pushed back on the queue with a schedule in the future as per the throttle settings. When the job is picked up again. the tries is 1, the max tries is still 1 thus is failes as it reached its maximum tries.

I think a throttle should leave the actual tries alone. There should be a specifiek max throttle tries or something. Or am i missing Laravel 11 logic here?

[ghost]

It is a solution for your case to work not to fix the throttles, yes.

[henzeb]

I wrote a method that releases a job back on the queue without a try. Basically it creates a new job, thus any changes are remembered.

Not sure if it helps with your situation, but if interested, I can share the code. It is quite simple really ...

[gldrenthe89]

I wrote a method that releases a job back on the queue without a try. Basically it creates a new job, thus any changes are remembered.

Not sure if it helps with your situation, but if interested, I can share the code. It is quite simple really ...

Thanks, but that is exactly what we have been doing for years. I wanted to start this discussion so maybe the throttle implementation would be updated to work a bit clever. As it stands now it is just missing that peice to be fully useable, am i right?

[henzeb]

for this usecase perhaps. Not for me. I am throttling on a different level. I have jobs generating hundreds of other jobs, and each needs to be run. If I have 15 jobs each generating 100 jobs, and when it reaches 1000 jobs in the queue , I want to stop generating jobs and release the job back on to the queue, so it can continue when the queue is below a certain threshold.

Releasing back on the queue in the vanilla laravel situation means a try (I don't think the maxExceptions has anything to do with that). and releasing back on the queue also means lost position (as if the job never ran).

[gldrenthe89]

The maxExceptions gives me a limit of only 1 exception. I always want to fail the job on a thrown exception. But not failing due to throttling being a additional try and when not throttling it having another try because de limit is 2. maxExceptions on 1 keeps it from trying a second time. At least thats in theory. I need to test this fully first.

[gldrenthe89]

Okay, maybe I found a way to work with this. I read in the documentation that there is a maxExceptions property. So if the max tries is set to 2 and the maxExceptions is set to 1, it should never run a second time when an exception is thrown. Throttling is not an exception, thus it should be able to throttle and still run the code and not retry upon an exception, even if there is still a retry left.

I will try to test this today.

[gldrenthe89]

Okay, maybe I found a way to work with this. I read in the documentation that there is a maxExceptions property. So if the max tries is set to 2 and the maxExceptions is set to 1, it should never run a second time when an exception is thrown. Throttling is not an exception, thus it should be able to throttle and still run the code and not retry upon an exception, even if there is still a retry left.

I will try to test this today.

Havn't found the time yet to test it. will try this week or next week

[gldrenthe89]

The logic as described works. It is throttling without failing. and on a exception it fails completely.

il leave the discussion open for other to see en find the info als to keep it moving.

As described above i did this different before. I will share my previous code below.

<?php

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Contracts\Redis\LimiterTimeoutException;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Redis;
use ReflectionClass;
use ReflectionException;
use ReflectionMethod;

abstract class ThrottleBaseJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    protected string $redisKey;

    protected int $allow = 60;

    protected int $interval = 60;

    protected bool $throttle = true;

    public function __construct()
    {
        $this->queue = 'throttled';
        $this->redisKey = get_class($this).'Api';
    }

    /**
     * Execute the job.
     *
     *
     * @throws ReflectionException|LimiterTimeoutException
     */
    public function handle(): void
    {
        if ($this->throttle) {
            Redis::throttle($this->redisKey)->allow($this->allow)->every($this->interval)->then(function () {
                $this->process();
            }, function () {
                $class = get_class($this);
                $parameters = new ReflectionMethod($class, '__construct');
                $parameters = $parameters->getParameters();
                $arguments = [];

                foreach ($parameters as $parameter) {
                    $arguments[] = $this->{$parameter->getName()};
                }

                $r = new ReflectionClass($class);

                // Dispatch new job soo it can run again when throttle is done
                dispatch($r->newInstanceArgs($arguments))
                    ->delay($this->interval)
                    ->chain($this->chained)
                    ->onQueue($this->queue);

                $this->chained = [];

                $this->delete();
            });

            return;
        }
        $this->process();
    }

    /**
     * Execute the job.
     */
    abstract public function process(): void;
}

[henzeb]

@gldrenthe89 There is no need to do reflection. In my case it is just back on the queue.

public function backOnTheQueue(): PendingDispatch
{
    $this->delete();
    $this->job = null;
    $this->delay = 0;
    $this->requeued += 1;

    $this->releaseLock();

    $job = clone $this;

    return dispatch($job)
        ->onQueue($this->queue)
        ->onConnection($this->connection);
}

public function releaseLock(): void
{
    if ($this instanceof ShouldBeUnique) {
        (new UniqueLock(Cache::store()))->release($this);
    }
}

Then in handle when you need to throttle you can call backOnTheQueue while preserving data that was changed in the job.

[gldrenthe89]

Thanks for the insight. This actually is a very old job (4+ years, laravel 5.6 or lower) that only has been updated when needed. This is our first time looking into a new cleaner logic. The one you just posted will defenitely be tried. Looks very clean. Thanks

[gldrenthe89]

Me again. I have used you class to update my class. Here is my current class that is use on everything that needs to be throttled. I dont reset the chained job because i need them.

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Contracts\Redis\LimiterTimeoutException;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Redis;
use ReflectionException;

abstract class ThrottleBaseJob implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    protected string $redisKey;

    protected int $allow = 60;

    protected int $interval = 60;

    protected bool $throttle = true;

    public function __construct()
    {
        $this->queue = 'throttled';
        $this->redisKey = get_class($this).'Api';
    }

    /**
     * @throws ReflectionException
     * @throws LimiterTimeoutException
     */
    public function handle(): void
    {
        if ($this->throttle) {
            Redis::throttle($this->redisKey)->allow($this->allow)->every($this->interval)->then(
                function () {
                    $this->process();
                }, function () {
                    // delete the job from the store en reset the attribute
                    $this->delete();
                    $this->job = null;

                    // reset the delay
                    $this->delay = 0;

                    // clone the job
                    $job = clone $this;

                    // dispatch
                    dispatch($job)
                        ->delay($this->interval)
                        ->onQueue($this->queue)
                        ->onConnection($this->connection);
                });

            return;
        }
        $this->process();
    }

    abstract public function process(): void;
}

[gldrenthe89]

I will close this now as i have everything up en runnning the way it should be. thanks @henzeb for you insights