[13.x] Boot managed queues before service providers boot#60198
Merged
taylorotwell merged 2 commits intoMay 20, 2026
Conversation
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.
This was referenced May 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Cloud::bootManagedQueues()registers thecloudqueue connector ($app['queue']->addConnector('cloud', ...)) and rebindsqueue.failer. It's currently hooked to thebootstrapperBootstrapped: BootProviders::classevent, which fires afterBootProviders::bootstrap()returns — i.e. after every service provider'sboot()has already run.Any application service provider whose
boot()touches the queue manager via the facade blows up underQUEUE_CONNECTION=cloud. For example:Queue::createPayloadUsing(...)proxies throughQueueManager::__call→$this->connection()→ resolves the default queue connection. WithQUEUE_CONNECTION=cloud, that fails withThe [cloud] queue connection has not been configuredbecause the connector hasn't been registered yet.Reproduction in a Cloud environment:
Fix
Move
bootManagedQueues()frombootstrapperBootstrapped: BootProviders::classtobootstrapperBootstrapping: BootProviders::class. This places it afterRegisterProvidersfinishes (soqueue/queue.failerare bound) but before any user provider'sboot()runs.While here, refactor the early-return guard. The previous
$_SERVER['LARAVEL_CLOUD_MANAGED_QUEUES']check overlapped with the env-driven configconfigureManagedQueues()already populates. Derive intent from observable state instead: only register the cloud connector whenqueue.connections.cloud.driver === 'cloud'. The outerlaravel_cloud()gate inApplication::registerLaravelCloudServices()already prevents these hooks from firing off-Cloud, so the duplicate environment check insidebootManagedQueuesis redundant.Test plan
tests/Foundation/Cloud/QueueTest.php— 36/36 passtestItDoesNotRegisterCloudConnectorWhenManagedQueuesIsInactivereworked into two tests covering the new conditions: missingqueue.connections.cloudblock, anddriver !== 'cloud'LARAVEL_CLOUD=1 LARAVEL_CLOUD_MANAGED_QUEUES=1 LARAVEL_CLOUD_MANAGED_QUEUES_CONFIG=... QUEUE_CONNECTION=cloud php artisan package:discover --ansinow succeeds where it previously threw