artisan queue:listen ignores changes in the .env file

[veencel]

• Laravel Version: 5.8.8
• PHP Version: 7.3.4
• Queue connection: Redis

Description:

When running the Illuminate\Queue\Console\ListenCommand command, changes in the .env file are ignored if the config is not cached.

The reason is that all environment variables are inherited by the Illuminate\Queue\Console\WorkCommand process, and when it loads the environment variables in Illuminate\Foundation\Bootstrap\LoadEnvironmentVariables, it doesn't overload existing values.

I'm using Laravel Forge, and when I start a worker using the UI and the Run Worker As Daemon option is unchecked, I have to restart the queue:listen command after changing something in the .env file.

Solution:

• I think the real solution is to remove the PutEnvAdapter as discussed here.
• Caching the configuration also solves the problem.
• Using the queue:work command instead of the queue:listen solves it, too. (queue can be restarted with the queue:restart command). On Forge, use the Run Worker As Daemon option.

This might not be an issue at all, queue:listen is not in the documentation, but when you create a worker on Forge with the default settings, it uses that command.
I'm opening this because I couldn't find anything about it, maybe it helps someone.

Steps To Reproduce:

• Clear configuration cache.
• Set the queue connection to something other than sync or null.
• Create a new job:

<?php

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Queue\SerializesModels;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Support\Facades\Log;

class Test implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public function handle()
    {
        Log::debug(config('app.name'));
    }
}

• Run: php artisan queue:listen
• Change app name in .env
• Dispatch a job somewhere: App\Jobs\Test::dispatch()
• Check the unchanged app name in the log file.

[driesvints]

You should always use queue:restart afaik when making changes to the env file?

[veencel]

That's true when you're using the queue:work command, because queue:restart instructs those processes to restart.

But when you use the queue:listen command, queue:work processes are started by that using the --once option, so those only process the next job on the queue.
Only the queue:work is listening for the restart signal broadcasted by queue:restart, queue:listen itself not.

So in this case, queue:restart is not doing anything, the queue:listen process needs the restart.

[driesvints]

I think that would mean that you'd have to halt the queue:listen and just restart it to refresh the process environment?

[veencel]

Yes, that's the problem. I think this is not the correct behaviour, when using the queue:listen command it shouldn't need any restart.
If I'm not wrong that's the difference between the listen and the work command.

queue:listen is missing from the documentation since v5.3, but it mentions the queue:restart command only for using daemon queue workers(queue:work).

[driesvints]

@veencel I'm afraid I don't agree with that. Any long-running process will need to be restarted when changes to the environment have been made. That's the way it has always worked afaik.

At the very least this seems more a feature request than a bug since the current behavior would be changed. So please open up an issue on the ideas repo to try to see how you'd change the internals in order to make this works.

Thanks