Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Niush's avatar

Niush wrote a reply+100 XP

4mos ago

Concurrency::run return error: Trying to access array offset on value of type null

I did some additional testing, and seems like the arrow function and closure behavior is super weird during serialization if there are multiple closures in a single line.

// This task-1/task-2 with arrow function in single line is not parsed correctly.
// And returns, $result = ["task-1" => 2, "task-2" => 2] incorrectly.
$result = Concurrency::run([ 'task-1' => fn() => 1 + 1, 'task-2' => fn() => 2 + 2 ]);

// But putting them in individual line fixes everything.
// $result = ["task-1" => 2, "task-2" => 4] correctly.
$result = Concurrency::run([
    'task-1' => fn() => 1 + 1,
    'task-2' => fn() => 2 + 2,
]);

It seems to be an issue with serialize, SerializableClosure, and ReflectionClosure implementation which is unable to determine which closure to use and always uses 1st function from the matching line.

I reported this issue here: https://github.com/laravel/serializable-closure/issues/119

Niush's avatar

Niush wrote a reply+100 XP

4mos ago

Concurrency::run return error: Trying to access array offset on value of type null

Your example code looks good (although there seems to be issue with Concurrency when using arrow function). It should return "2 and 4", but it is returning "2 and 2" for me.

But the main error "Trying to access array offset on value of type null" may happen if you try to do echo/dump inside the concurrency function. Example like this:

[$task1, $task2] = Concurrency::run([
    function () {
        dump('Task 1 running');
        return 1;
    },
    function () {
        echo('Task 2 running');
        return 2;
    },
]);

We cannot use echo/dump and should only return serializable data.

Niush's avatar

Niush wrote a reply+100 XP

4mos ago

Seeing the json data instead of the vue component pages?

It's most likely because of Vary header getting replaced.

More Info: https://github.com/inertiajs/inertia/issues/1591#issuecomment-2679536776

I also had this issue when deployed behind AWS CloudFront, which automatically added Vary: Accept-Encoding as mentioned in the issue above.