Job Batching not Working

[garissman]

• Laravel-mongodb Version: v3.8.1
• PHP Version: 7.4.9
• Laravel Version: v8.15.0
• Database Driver & Version: jenssegers/mongodb v3.8.1

Description:

Trying to get property 'id' of non-object on vendor/laravel/framework/src/Illuminate/Bus/DatabaseBatchRepository.php:256

Steps to reproduce

1. Just create the Bus like:

use App\Jobs\ProcessPodcast;
use App\Podcast;
use Illuminate\Bus\Batch;
use Illuminate\Support\Facades\Bus;
use Throwable;

$batch = Bus::batch([
    new ProcessPodcast(Podcast::find(1)),
    new ProcessPodcast(Podcast::find(2)),
    new ProcessPodcast(Podcast::find(3)),
    new ProcessPodcast(Podcast::find(4)),
    new ProcessPodcast(Podcast::find(5)),
])->then(function (Batch $batch) {
    // All jobs completed successfully...
})->catch(function (Batch $batch, Throwable $e) {
    // First batch job failure detected...
})->finally(function (Batch $batch) {
    // The batch has finished executing...
})->dispatch();

Expected behaviour

in Illuminate\Bus\DatabaseBatchRepository::find

$batch = $this->connection->table($this->table)
                            ->where('id', $batchId)
                            ->first();
// $batch should be a object instead of array
if ($batch) {
// the error is trigger by this method "toBatch"
    return $this->toBatch($batch);
}

    protected function toBatch($batch)
    {
        return $this->factory->make(
            $this,
            $batch->id, // this $batch is a array and not a object
            $batch->name,
            (int) $batch->total_jobs,
            (int) $batch->pending_jobs,
            (int) $batch->failed_jobs,
            json_decode($batch->failed_job_ids, true),
            unserialize($batch->options),
            CarbonImmutable::createFromTimestamp($batch->created_at),
            $batch->cancelled_at ? CarbonImmutable::createFromTimestamp($batch->cancelled_at) : $batch->cancelled_at,
            $batch->finished_at ? CarbonImmutable::createFromTimestamp($batch->finished_at) : $batch->finished_at
        );
    }

Actual behaviour

in Illuminate\Bus\DatabaseBatchRepository::find

$batch = $this->connection->table($this->table)
                            ->where('id', $batchId)
                            ->first();
// it returns a array and not a object

Thanks

[MartMoiseev]

Same problem! Try on MongoDB and MySQL.

[NiekNijland]

Same problem here:

[stadeleon]

The same issue in Laravel 8.53.1 because of $batch is array but trying to get id like object

[stadeleon]

if make this fix to test $batch = (object)$batch; than got next error in vendor/laravel/framework/src/Illuminate/Bus/PendingBatch.php

[Giacomo92]

Hi @stadeleon, in order to fix this issue this PR #1904 has to be merge

[alameenpa]

Bus::batch will not work with MongoDB.

Currently not supporting, may be in feature releases.

[lucasemanuel]

has this already been resolved?

[AlifAbhiesa]

Is any progress about this issue?

[puuble]

Same :(

Is any progress about this issue?

[d-uvin]

Try to extend that DatabaseBatchRepository in providers by creating custom class with redeclared find() method

[oktaykalfa]

Hello, this problem still persists. Is there any update?

Laravel version: 8.83.23 PHP version: 8.1.6 Laravel-mongodb Version: v3.8.1 Database Driver & Version: jenssegers/mongodb v3.8.1

[masitings]

Is there any update for batching ? i've try hybrid using mysql for batches only. What i do is i change the config of queue where there is a batch array says 'batching' . It work for creating the batch, but im not sure all the queue goes to mongodb instead. Really need batching to be worked!

[alcaeus]

I see a couple of problems using the default DatabaseBatchRepository class:

1. The class uses id for its primary key, but MongoDB uses _id. This makes all queries on id unindexed
2. The above also causes the id property to have no unique constraint unless people run a migration for that collection
3. The query builder returned by the ->table() call uses a type map specifying arrays for root documents and embedded documents. This causes the issue of receiving an array when the repository expects an object. However, this is not something we can generally change.

With that in mind, the solution will most likely involve creating a separate repository class that doesn't have the issues mentioned above.

I've created PHPORM-81 to track this internally.