`Concurrency::run` fails silently if `zlib.output_compression` is turned on

[dj0rdj3]

Laravel Version

12.53.0

PHP Version

8.4.13

Database Driver & Version

No response

Description

Concurrency::run fails silently when zlib.output_compression is enabled. The only visible error is Trying to access array offset on null at ProcessDriver.php:51. After much investigation, it turns out that zlib.output_compression = On in php.ini appends compressed binary data to the child process stdout after the JSON payload. json_decode returns null on the corrupted string, causing the array offset error in the parent.
Suggested fix: add a check in ProcessDriver::run() before spawning processes:

if (ini_get('zlib.output_compression')) {
    throw new \RuntimeException('Concurrency process driver requires zlib.output_compression to be disabled.');
}

Steps To Reproduce

In php.ini, set zlib.output_compression = On
Call the following code from any controller:

Concurrency::run([fn() => sleep(1)]);

Observe the cryptic Trying to access array offset on null error at ProcessDriver.php:51

[NikhiltGhalme]

Hi @dj0rdj3, I’d like to take this issue.

Proposed approach:

I plan to introduce a validation check inside ProcessDriver::run() to detect whether zlib.output_compression is enabled. If it is, the method will throw a clear RuntimeException before attempting to spawn child processes. This should prevent unexpected behavior caused by output buffering conflicts.

Example:

if (ini_get('zlib.output_compression')) {
throw new RuntimeException(
'Concurrency process driver requires zlib.output_compression to be disabled.'
);
}

Additionally, I will include a test case to ensure this scenario is properly covered and validated.

Target branch: 12.x (following the project’s bug-fix contribution guidelines).

Please let me know if this approach aligns with your expectations before I proceed with the PR. Thank you!

[iBotPeaches]

@NikhiltGhalme - I subscribed to this, do you think its a hard blocker and it has to be disabled? Or its a problem that can be resolved with the value enabled or not.

[NikhiltGhalme]

@iBotPeaches Good point — I agree that it doesn’t need to be treated as a hard blocker. Instead of throwing an exception, we could address it by disabling zlib.output_compression within the child process before it outputs the JSON.

For example, we could add something like:

ini_set('zlib.output_compression', '0');

in the child process script so the parent process always receives clean JSON, regardless of the user’s global PHP configuration.

This would allow Concurrency::run() to function transparently without requiring users to modify their php.ini. I’ll adjust my approach accordingly and open a PR with this solution.

[iBotPeaches]

@NikhiltGhalme - then final point, can we detect the compression and handle it instead of changing the value at all?

[NikhiltGhalme]

@iBotPeaches That’s a good direction. Instead of altering zlib.output_compression, we can simply handle the situation on the parent side.

In some cases the child process output may include gzip-compressed data appended after the JSON payload. If that happens, we can detect it by looking for the gzip magic bytes (\x1f\x8b). When found, we can trim everything after that point so only the valid JSON remains before decoding.

Example:

$output = $process->getOutput();

// Remove any gzip-compressed data appended due to zlib.output_compression
if (($gzipPos = strpos($output, "\x1f\x8b")) !== false) {
$output = substr($output, 0, $gzipPos);
}

$result = json_decode($output, true);

This approach avoids changing the user’s PHP configuration and simply makes the parent process resilient to whatever the child process outputs. I’ll implement it this way in the PR.

[dj0rdj3]

@NikhiltGhalme I agree with the least intrusive approach, that would be the best.

[NikhiltGhalme]

@iBotPeaches Thanks for the guidance! I'll open a PR with the detection-based approach shortly.