Crash when using print statement inside closure in Concurrency Facade

[rcalicdan]

Laravel Version

12.28.1

PHP Version

8.4.5

Database Driver & Version

No response

Description

When using Laravel’s Concurrency::run() feature, the process crashes with Trying to access array offset on null in ProcessDriver.php if a closure contains echo or print. This happens because child processes communicate back to the parent via JSON, and printing to STDOUT corrupts the expected JSON payload, causing $result to become null. Instead of crashing, Laravel should either gracefully handle extra output, redirect it, or clearly document that closures should not use direct output and should return values or use logging instead. Please take a look at this critical architectural flaw.

Steps To Reproduce

`<?php

use Illuminate\Support\Facades\Concurrency;
use Library\Defer\Parallel;

require "vendor/autoload.php";
$app = require "bootstrap/app.php";
$kernel = $app->make(Illuminate\Contracts\Console\Kernel::class);
$kernel->bootstrap();

$start1 = microtime(true);
Concurrency::run([
function () {
sleep(1);
echo "Task 1 done";
},
function () {
sleep(2);
echo "Task 2 done";
},
function () {
sleep(3);
echo "Task 3 done";
},
]);
$end1 = microtime(true);
echo 'Concurrency time: ' . ($end1 - $start1) . " seconds\n";
`

`C:\Laravel\test-herd>php test.php

ErrorException

Trying to access array offset on null

at vendor\laravel\framework\src\Illuminate\Concurrency\ProcessDriver.php:51
47▕ }
48▕
49▕ $result = json_decode($result->output(), true);
50▕
➜ 51▕ if (! $result['successful']) {
52▕ throw new $result['exception'](
53▕ ...(! empty(array_filter($result['parameters']))
54▕ ? $result['parameters']
55▕ : [$result['message']])

1 vendor\laravel\framework\src\Illuminate\Concurrency\ProcessDriver.php:51
Illuminate\Foundation\Bootstrap\HandleExceptions::{closure:Illuminate\Foundation\Bootstrap\HandleExceptions::forwardsTo():257}("Trying to access array offset on null", "C:\Laravel\test-herd\vendor\laravel\framework\src\Illuminate\Concurrency\ProcessDriver.php")

2 vendor\laravel\framework\src\Illuminate\Collections\Arr.php:803
Illuminate\Concurrency\ProcessDriver::{closure:Illuminate\Concurrency\ProcessDriver::run():44}()
`

[Sandalanka]

You’ve actually uncovered a real design limitation in Laravel 12’s new concurrency API.

Right now, Concurrency::run() relies on ProcessDriver, which launches child PHP processes and communicates back to the parent using JSON payloads over STDOUT.

Why it crashes

Your closures call echo (or print), which writes directly to STDOUT.

Since STDOUT is also being used by Laravel to pass structured JSON-encoded results, your raw text corrupts the JSON.

When Laravel tries json_decode($result->output(), true), it fails → $result becomes null.

That’s why you get:

Trying to access array offset on null in ProcessDriver.php

Workarounds you can use now

Don’t use echo or print inside concurrent tasks
Instead, return values or log them:

Concurrency::run([
fn() => 'Task 1 done',
fn() => 'Task 2 done',
fn() => 'Task 3 done',
]);

Or:

use Illuminate\Support\Facades\Log;

Concurrency::run([
fn() => Log::info('Task 1 done'),
fn() => Log::info('Task 2 done'),
]);

Capture output manually
If you really need “print-style” behavior, wrap output buffering:

Concurrency::run([
function () {
ob_start();
echo "Task 1 done";
return ob_get_clean();
},
]);

This way, the closure returns the string instead of contaminating STDOUT.

What Laravel should ideally do

Document this clearly (like “closures must not write to STDOUT, use return/logging instead”).

Or sandbox STDOUT so any echo/print goes to a buffer and doesn’t corrupt JSON.

Or gracefully handle invalid JSON, returning a descriptive error instead of crashing with “Trying to access array offset on null”.

[rcalicdan]

Oh thank you, I think the one thing I really don't like about this facade is its misleading name, and had nothing to do on real concurrency. Laravel should be honest or at least document its limitation to its users.