Provide a method that allows to obtain the Job Id from a dispatched job.

[juanparati]

I observed that a some point in Laravel 10.x is not possible to obtain the dispatched job Id from a controller. It could be nice if "\Illuminate\Foundation\Bus\PendingDispatch" implements a method that allow to obtain the job id in a easy way.

I known that is possible to have the old behaviour calling the method "dispatch" from "\Illuminate\Contracts\Bus\Dispatcher::class" (Ex: app(\Illuminate\Contracts\Bus\Dispatcher::class)->dispatch($job)), but it could be very more convenient having a method for "PendingDispatch".

I also observed that Laravel upgrade guide doesn't mention this change.

[henzeb]

The thing is, PendingDispatch, does not dispatch until __destruct. until then, there's no Id.
Jobs do have the ability to have uniqueId's though.

not sure what you wanted to do with the Id?

[Silidrone]

I have "scheduled tasks" sort of a thing in my app, where I want to generate tasks that will run in x amount of time (so I use delayed jobs) but I want the user to be able to "cancel" them. I would accomplish this by deleting the related job. But how can I know which job is related? I create the delayed job but I can never get it's id to save it to the task. That's where I'd need to use the id. Any suggestions?

[DimaVIII]

I have a similar issue here #48107
Currently PendingDispatch is a blackbox in the tail of a plane.

My suggestion would be to give PendingDispatch some events so we can react to the behaviour.

You can try use this package to track jobs: https://github.com/mateusjunges/trackable-jobs-for-laravel
We are tracking jobs in the this package via a polymorphic relationship. So you can obtain all tracked jobs easy by App\Models\YourModel::first()->jobs

Here is my PR for v2 which include Job ID tracking (work in progress): https://github.com/DimaVIII/trackable-jobs-for-laravel/tree/features-v2
In this PR I'm tracking the Job ID over the middleware.
By now I found a better solution, listening to the Event \Illuminate\Queue\Events\JobQueued::class.

Than updating the Job ID:

    public function handle(JobQueued $event): void
    {
        if (isset($event->job->trackedJob))
        {
            $event->job->trackedJob->markAsQueued($event->id);
        }
    }

[Silidrone]

I didn't want to mess around with it for too long as I saw there isn't a legitimate solution provided in the Laravel docs so I solved my problem using a workaround. I had a Model I was manipulating inside the job (it was connected one-on-one with the job), so instead of accepting the model object I changed the job's constructor to accept the id. When I delay dispatch the job, in it's handle method, I query for that object with the id provided in the constructor earlier. Then, I check for a boolean flag inside of that model (meanwhile, before the job is actually executed, I update the object's flag field to true in the DB, so that I know it should be cancelled). I guess this could be done either way, even if you don't have such logic present you could introduce another table and solve the issue, but I believe it is not the best solution out there.

[jaymoh]

I will just downgrade to laravel 9 as the job ID is a crucial feature, and I have an underlying logic that has been using it in previous applications. In my flow, a user initiates a long-running process (generating downloadable statement files), so I send them the jobId from $jobId = $this->dispatchSync($job), and the front end keeps polling the backend with the jobId to see if it's running, failed, or completed. When the job starts running it creates a model in the database with the jobId, and updates the model appropriately during its lifecycle.

[LMCom]

I will just downgrade to laravel 9 as the job ID is a crucial feature, and I have an underlying logic that has been using it in previous applications. In my flow, a user initiates a long-running process (generating downloadable statement files), so I send them the jobId from $jobId = $this->dispatchSync($job), and the front end keeps polling the backend with the jobId to see if it's running, failed, or completed. When the job starts running it creates a model in the database with the jobId, and updates the model appropriately during its lifecycle.

That is my use-case, too. That's why I ended up here.

[flow96]

For anyone having the same problem and coming here to find a solution - you can use one of the following methods instead to dispatch a job and get the jobId instantly:

$job = new YourJob();
$jobId = Bus::dispatch($job);
// Or
$jobId = Queue::push($job);

It's stated in the Laravel documentation for Tinker (below in the info box): https://laravel.com/docs/12.x/artisan#usage