Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bus::batch ignores job queue, while Bus::chain respects #54286

Open
vadimonus opened this issue Jan 21, 2025 · 7 comments
Open

Bus::batch ignores job queue, while Bus::chain respects #54286

vadimonus opened this issue Jan 21, 2025 · 7 comments

Comments

@vadimonus
Copy link

vadimonus commented Jan 21, 2025

Laravel Version

11

PHP Version

any supported

Database Driver & Version

No response

Description

Having some job with filled queue with onQueue call.
When I call Bus::chain([$job1, $job2]) they are pushed to specified queue.
When I call Bus::batch([$job1, $job2]) they are pushed to queue default.
Documentation https://laravel.com/docs/11.x/queues#batch-connection-queue is not very clear about this behaviour, only mentions, that queue should be same, and it is same.
Such inconsistent behavior between Chain and Batch is very confusing.

It this behaviour a bug (in this case i will provide PR with fix in code) or it is expected (in this case i will provide PR to documentation, clarifying this behavior) ?

Steps To Reproduce

create ProcessPodcast job with onQueue (second example in) https://laravel.com/docs/11.x/queues#dispatching-to-a-particular-queue
Run Bus::chain([new ProcessPodcast]) and Bus::batch([new ProcessPodcast]) and see, that batch send job to default queue, while chain to processing queue.

@crynobone
Copy link
Member

Hey there, thanks for reporting this issue.

We'll need more info and/or code to debug this further. Can you please create a repository with the command below, commit the code that reproduces the issue as one separate commit on the main/master branch and share the repository here?

Please make sure that you have the latest version of the Laravel installer in order to run this command. Please also make sure you have both Git & the GitHub CLI tool properly set up.

laravel new bug-report --github="--public"

Do not amend and create a separate commit with your custom changes. After you've posted the repository, we'll try to reproduce the issue.

Thanks!

@laravel laravel deleted a comment from github-actions bot Jan 22, 2025
@crynobone
Copy link
Member

I believe you should be able to follow PendingChain code by getting the first job and get $firstJob->queue from there, but at the same time this also feels incorrect as if 2nd...n job has a different queue it would still use the first job's queue.

@vadimonus
Copy link
Author

@crynobone currently the question is if such difference in behaviour between chain and batch is bug, or it is expected behaviour?
Depending on it i'll bring PR to code or to documentation.

@vadimonus
Copy link
Author

BatchJobs was introduced in #32830 by taylorotwell
@taylorotwell , please give some comments.
Do you think it's better to respect jobs connection and queue (it's possible) to make chain and batch behaviour more simular. Or better to clarify documentation?

@ercsctt
Copy link

ercsctt commented Feb 4, 2025

https://laravel.com/docs/11.x/queues#batch-connection-queue This is definitely intended behaviour that batched jobs should be on the same queue.

All batched jobs must execute within the same connection and queue

However, you can override this in your application, here's an example I did with horizon (applies to normal queue workers too I'd imagine):

<?php

namespace App\Domain\Overrides\MultiQueueBatching\Providers;

use App\Domain\Overrides\MultiQueueBatching\Connectors\RedisConnector;
use Illuminate\Queue\QueueManager;
use Illuminate\Support\ServiceProvider;

class QueueServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        $this->registerRedisConnector();
    }

    private function registerRedisConnector(): void
    {
        $this->callAfterResolving(QueueManager::class, function ($manager) {
            $manager->addConnector('redis', function () {
                return new RedisConnector($this->app['redis']);
            });
        });
    }
}
<?php

namespace App\Domain\Overrides\MultiQueueBatching\Connectors;

use App\Domain\Overrides\MultiQueueBatching\RedisQueue;
use Illuminate\Support\Arr;
use Laravel\Horizon\Connectors\RedisConnector as Connector;

class RedisConnector extends Connector
{
    public function connect(array $config): RedisQueue
    {
        return new RedisQueue(
            $this->redis, $config['queue'],
            Arr::get($config, 'connection', $this->connection),
            Arr::get($config, 'retry_after', 60),
            Arr::get($config, 'block_for', null),
            Arr::get($config, 'after_commit', null)
        );
    }
}
<?php

namespace App\Domain\Overrides\MultiQueueBatching;

class RedisQueue extends \Laravel\Horizon\RedisQueue
{
    public function push($job, $data = '', $queue = null)
    {
        $queue = $queue ?? $job->queue ?? $this->default;

        return parent::push($job, $data, $queue);
    }
}

This may not work in every case, and you may encounter race conditions, but it works well for me.

@vadimonus
Copy link
Author

vadimonus commented Feb 4, 2025

@ercsctt

https://laravel.com/docs/11.x/queues#batch-connection-queue This is definitely intended behaviour that batched jobs should be on the same queue.

All batched jobs must execute within the same connection and queue

If you have read issue, i have two jobs with same (but not default) queue and connection. But when i call Bus::batch([$job1, $job2]) they are pushed to default queue. And this point is not clear from documentation and behaves not consistent with Bus::chain.

I'm not asking about code examples for my application.
I'm asking what should be improved, framework (to respect job's queue and connection) or documentation (clearly saying that Bus::batch ignores job's queue and connection).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants