Skip to content

[12.x] Boot managed queues before service providers boot - #60199

Merged
taylorotwell merged 2 commits into
laravel:12.xfrom
kieranbrown:boot-managed-queues-before-providers-12.x
May 20, 2026
Merged

taylorotwell merged 2 commits into
laravel:12.xfrom
kieranbrown:boot-managed-queues-before-providers-12.x

Conversation

@kieranbrown

Copy link
Copy Markdown
Member

Backport of #60198 to 12.x.

Summary

Cloud::bootManagedQueues() registers the cloud queue connector and rebinds queue.failer. It's currently hooked to bootstrapperBootstrapped: BootProviders::class, which fires after every service provider's boot() has already run.

Any application service provider whose boot() touches the queue manager via the facade blows up under QUEUE_CONNECTION=cloud. For example:

public function boot(): void
{
    Queue::createPayloadUsing(fn ($connection, $queue, $payload) => /* … */);
}

Queue::createPayloadUsing(...) proxies through QueueManager::__call → $this->connection() → resolves the default connection. With QUEUE_CONNECTION=cloud that fails with The [cloud] queue connection has not been configured because the connector hasn't been registered yet.

Reproduction in a Cloud environment:

QUEUE_CONNECTION=cloud php artisan package:discover --ansi

Fix

Move bootManagedQueues() from bootstrapperBootstrapped: BootProviders::class to bootstrapperBootstrapping: BootProviders::class. This places it after RegisterProviders (so queue / queue.failer are bound) but before any user provider's boot() runs.

While here, refactor the early-return guard. The previous $_SERVER['LARAVEL_CLOUD_MANAGED_QUEUES'] check overlapped with the env-driven config configureManagedQueues() already populates. Derive intent from observable state instead: only register the cloud connector when queue.connections.cloud.driver === 'cloud'. The outer laravel_cloud() gate in Application::registerLaravelCloudServices() already prevents these hooks from firing off-Cloud, so the duplicate environment check is redundant.

A follow-up commit drops the now-unused LARAVEL_CLOUD_MANAGED_QUEUES env from the test setUp/tearDown.

Test plan

  • tests/Foundation/Cloud/QueueTest.php — 36/36 pass
  • vendor/bin/pint clean on changed files
  • Existing testItDoesNotRegisterCloudConnectorWhenManagedQueuesIsInactive reworked into two tests covering the new conditions: missing queue.connections.cloud block, and driver !== 'cloud'

The `cloud` queue connector was registered on the `bootstrapperBootstrapped: BootProviders` event, meaning it fired after every service provider's `boot()` had already run. Application providers whose boot logic touches the queue (e.g. `Queue::createPayloadUsing(...)`, which proxies through `QueueManager::__call` and resolves the default connection) blow up under `QUEUE_CONNECTION=cloud` with "The [cloud] queue connection has not been configured", because the connector isn't registered yet.

Move `bootManagedQueues()` to `bootstrapperBootstrapping: BootProviders` so it runs after `RegisterProviders` (queue/queue.failer are bound) but before any user provider's `boot()`.

Also refactor the early-return guard. The previous check on `$_SERVER['LARAVEL_CLOUD_MANAGED_QUEUES']` overlapped with the env-driven config that `configureManagedQueues()` already populates. Derive intent from observable state instead: only register the cloud connector if `queue.connections.cloud.driver === 'cloud'`. The outer `laravel_cloud()` gate in `Application::registerLaravelCloudServices()` already prevents these hooks from firing off-Cloud.
No production code reads this env var anymore — the previous commit replaced its only consumer (the guard in `bootManagedQueues`) with a check on `queue.connections.cloud.driver`. The setUp/tearDown lines in `tests/Foundation/Cloud/QueueTest.php` are the only remaining references; remove them.

`LARAVEL_CLOUD_MANAGED_QUEUES_CONFIG` is a different env var and is still consumed by `configureManagedQueues()` — left in place.
@taylorotwell
taylorotwell merged commit 0132e69 into laravel:12.x May 20, 2026
22 of 72 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants