[12.x] feat: --memory=0 should mean skip memory exceeded verification (Breaking Change)

[mathiasgrimm]

Memory Limit Behavior Change for Queue Workers

Current Behavior

When running Laravel queue workers with --memory=0:

php artisan queue:listen --memory=0
php artisan queue:work --memory=0

The worker currently exits with static::EXIT_MEMORY_LIMIT after processing each job, regardless of the actual memory usage. The only exceptions are when:

• The connection is lost
• A SIGQUIT signal is received

Issue

The current implementation treats 0 as a special value that forces worker termination, but this behavior is inconsistent with how zero values are handled in other parts of the Worker class. Here are the relevant examples:

// Illuminate\Queue\Worker::daemon:180
if ($options->rest > 0) {
    $this->sleep($options->rest);
}

// Illuminate\Queue\Worker::pauseWorker:289
$this->sleep($options->sleep > 0 ? $options->sleep : 1);

// Illuminate\Queue\Worker::markJobAsFailedIfWillExceedMaxAttempts:550
if (! $job->retryUntil() && $maxTries > 0 && $job->attempts() >= $maxTries) {
    $this->failJob($job, $e);
}

In all these cases, zero is treated as a way to disable the feature rather than trigger special behavior.

Proposed Change

We should modify the memory limit check to align with other worker options' behavior. When --memory=0 is specified, it should disable memory limit checking entirely instead of forcing worker termination after each job.

This change would:

1. Make the behavior more intuitive and consistent with other worker options
2. Allow for true continuous processing when memory limits aren't needed
3. Maintain the ability to set specific memory limits when required

Implementation Notes

The change would involve modifying how zero values are interpreted in the memory limit checks, similar to how other worker options handle zero values:

// Proposed behavior:
public function memoryExceeded($memoryLimit)
{
    return $memoryLimit > 0 && (memory_get_usage(true) / 1024 / 1024) >= $memoryLimit;
}

Backward Compatibility

This is a breaking change as it modifies existing behavior. It should be:

1. Documented clearly in the release notes
2. Included in a major version release
3. Accompanied by clear migration instructions for users who rely on the current behavior