Horizon restarting but old code is being used

[Braunson]

• Using Forge
• Laravel 5.7
• Laravel Horizon 1.3.1

On deploy we are restarting PHP-FPM and running..

php artisan horizon:terminate
php artisan horizon:purge

However jobs are failing due to using old code, in one example it's using Auth::loginUsingId(1) but is throwing an error as it expects 3 params but receiving two. This was a change from Laravel 5.6 -> 5.7. For some reason it's using old code.

Error:

Symfony\Component\Debug\Exception\FatalThrowableError: Too few arguments to function Illuminate\Auth\Events\Login::__construct(), 2 passed in /home/forge/project/vendor/laravel/framework/src/Illuminate/Auth/SessionGuard.php on line 598 and exactly 3 expected in /home/forge/project/vendor/laravel/framework/src/Illuminate/Auth/Events/Login.php:40

Looks like Illuminate/Auth/Events/Login __construct expects three params in 5.7 but is receiving two (missing the $guard).

---

Full Stack

Symfony\Component\Debug\Exception\FatalThrowableError: Too few arguments to function Illuminate\Auth\Events\Login::__construct(), 2 passed in /home/forge/project/vendor/laravel/framework/src/Illuminate/Auth/SessionGuard.php on line 598 and exactly 3 expected in /home/forge/project/vendor/laravel/framework/src/Illuminate/Auth/Events/Login.php:40
Stack trace:
#0 /home/forge/project/vendor/laravel/framework/src/Illuminate/Auth/SessionGuard.php(598): Illuminate\Auth\Events\Login->__construct(Object(App\Models\User), false)
#1 /home/forge/project/vendor/laravel/framework/src/Illuminate/Auth/SessionGuard.php(422): Illuminate\Auth\SessionGuard->fireLoginEvent(Object(App\Models\User), false)
#2 /home/forge/project/vendor/laravel/framework/src/Illuminate/Auth/SessionGuard.php(391): Illuminate\Auth\SessionGuard->login(Object(App\Models\User), false)
#3 /home/forge/project/vendor/laravel/framework/src/Illuminate/Auth/AuthManager.php(292): Illuminate\Auth\SessionGuard->loginUsingId(1)
#4 /home/forge/project/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(223): Illuminate\Auth\AuthManager->__call('loginUsingId', Array)
#5 /home/forge/project/app/Jobs/CallList/BookOfBusinessProcess.php(30): Illuminate\Support\Facades\Facade::__callStatic('loginUsingId', Array)
#6 [internal function]: App\Jobs\CallList\BookOfBusinessProcess->handle(Object(App\Services\ContactService), Object(App\Services\CampaignService), Object(App\Services\CampaignTypeService), Object(App\Services\OpportunityService), Object(App\Services\ActionLogService))
#7 /home/forge/project/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(29): call_user_func_array(Array, Array)
#8 /home/forge/project/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(87): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}()
#9 /home/forge/project/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(31): Illuminate\Container\BoundMethod::callBoundMethod(Object(Illuminate\Foundation\Application), Array, Object(Closure))
#10 /home/forge/project/vendor/laravel/framework/src/Illuminate/Container/Container.php(564): Illuminate\Container\BoundMethod::call(Object(Illuminate\Foundation\Application), Array, Array, NULL)
#11 /home/forge/project/vendor/laravel/framework/src/Illuminate/Bus/Dispatcher.php(94): Illuminate\Container\Container->call(Array)
#12 /home/forge/project/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(116): Illuminate\Bus\Dispatcher->Illuminate\Bus\{closure}(Object(App\Jobs\CallList\BookOfBusinessProcess))
#13 /home/forge/project/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php(104): Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Object(App\Jobs\CallList\BookOfBusinessProcess))
#14 /home/forge/project/vendor/laravel/framework/src/Illuminate/Bus/Dispatcher.php(98): Illuminate\Pipeline\Pipeline->then(Object(Closure))
#15 /home/forge/project/vendor/laravel/framework/src/Illuminate/Queue/CallQueuedHandler.php(49): Illuminate\Bus\Dispatcher->dispatchNow(Object(App\Jobs\CallList\BookOfBusinessProcess), false)
#16 /home/forge/project/vendor/laravel/framework/src/Illuminate/Queue/Jobs/Job.php(83): Illuminate\Queue\CallQueuedHandler->call(Object(Illuminate\Queue\Jobs\RedisJob), Array)
#17 /home/forge/project/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(326): Illuminate\Queue\Jobs\Job->fire()
#18 /home/forge/project/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(276): Illuminate\Queue\Worker->process('redis', Object(Illuminate\Queue\Jobs\RedisJob), Object(Illuminate\Queue\WorkerOptions))
#19 /home/forge/project/vendor/laravel/framework/src/Illuminate/Queue/Worker.php(118): Illuminate\Queue\Worker->runJob(Object(Illuminate\Queue\Jobs\RedisJob), 'redis', Object(Illuminate\Queue\WorkerOptions))
#20 /home/forge/project/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(101): Illuminate\Queue\Worker->daemon('redis', 'default', Object(Illuminate\Queue\WorkerOptions))
#21 /home/forge/project/vendor/laravel/framework/src/Illuminate/Queue/Console/WorkCommand.php(85): Illuminate\Queue\Console\WorkCommand->runWorker('redis', 'default')
#22 [internal function]: Illuminate\Queue\Console\WorkCommand->handle()
#23 /home/forge/project/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(29): call_user_func_array(Array, Array)
#24 /home/forge/project/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(87): Illuminate\Container\BoundMethod::Illuminate\Container\{closure}()
#25 /home/forge/project/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(31): Illuminate\Container\BoundMethod::callBoundMethod(Object(Illuminate\Foundation\Application), Array, Object(Closure))
#26 /home/forge/project/vendor/laravel/framework/src/Illuminate/Container/Container.php(564): Illuminate\Container\BoundMethod::call(Object(Illuminate\Foundation\Application), Array, Array, NULL)
#27 /home/forge/project/vendor/laravel/framework/src/Illuminate/Console/Command.php(179): Illuminate\Container\Container->call(Array)
#28 /home/forge/project/vendor/symfony/console/Command/Command.php(251): Illuminate\Console\Command->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Illuminate\Console\OutputStyle))
#29 /home/forge/project/vendor/laravel/framework/src/Illuminate/Console/Command.php(166): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Illuminate\Console\OutputStyle))
#30 /home/forge/project/vendor/symfony/console/Application.php(886): Illuminate\Console\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#31 /home/forge/project/vendor/symfony/console/Application.php(262): Symfony\Component\Console\Application->doRunCommand(Object(Laravel\Horizon\Console\WorkCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#32 /home/forge/project/vendor/symfony/console/Application.php(145): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#33 /home/forge/project/vendor/laravel/framework/src/Illuminate/Console/Application.php(89): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#34 /home/forge/project/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(122): Illuminate\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#35 /home/forge/project/artisan(37): Illuminate\Foundation\Console\Kernel->handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#36 {main}

[mfn]

#5 /home/forge/project/app/Jobs/CallList/BookOfBusinessProcess.php(30): Illuminate\Support\Facades\Facade::__callStatic('loginUsingId', Array)

Did you adapt this line in your code to use 3 args?

[Braunson]

@mfn That's the thing, I'm using Auth::loginUsingId(1) which doesn't accept three params, only two (User, remember bool). So it leads me to believe that the queue job is using old Laravel/Framework code somehow..

[driesvints]

Can you try upgrading to the latest Horizon version? Can you try switching the purge and terminate commands?

[Braunson]

@driesvints I'm using the latest version. I've added purge to the deploy process now (I was already using terminate).

[sebastiaanluca]

Maybe see #213 for the correct commands and order to use when deploying.

[loshmis]

Hmm... I also have the similar issue, but on my end it is related to the emails. Basically, the app is using a default css theme instead of the updated one, but not always...

I'm using the latest version of Horizon and the list of commands I run on deploy are the following (as suggested in #213 ):

git pull origin master
composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader

php artisan migrate --force
php artisan route:cache
php artisan config:cache

echo "" | sudo -S service php7.2-fpm reload

php artisan horizon:purge
php artisan horizon:terminate
php artisan queue:restart

So, after I deploy and test things, it is using a new css theme that I've created and everything is working as it should. However, from time to time I get the same email but with old css theme, which makes things even more weird. It's like there is a process that is still running the old code or something...

I haven't tried to reboot the server since it is a production machine, but I'll guess I'll have to try that and see if it will solve the issue.

If someone has an idea what can be the issue and how to fix it, please let me know.

[loshmis]

For those who are interested, here is what was the issue on my end and how I solved it.

So, as described above, I had an issue with email templates.

The way my app was set up is the following:

• There are two different CSS themes: default.css and other.css
• Most of the emails and notifications are using a default.css theme, but there are few emails that use the other.css theme
• Some emails are built and send directly from the toMail() method of a specific notification, without a dedicated mailable class

After a lot of testing, I figured out that the problem only occurs after an email that uses other.css theme is sent. After such email, all other emails will use the other.css theme instead of a default.css, as it is specified inside the config file.

The solution I had for this issue is to add a dedicated Mailable class for each email, instead of building an email from the toMail() method of the Notification class, and then explicitly specify the protected $theme = 'default'; for each of those emails.

I'm not sure why this happens but hopefully it will help someone with a similar problem.

[mfn]

After a lot of testing, I figured out that the problem only occurs after an email that uses other.css theme is sent. After such email, all other emails will use the other.css theme instead of a default.css, as it is specified inside the config file.

That sounds a lot like the class gets only instantiated once and this instance is then subsequently re-used.

Horizons (or for that matter, Laravels) worker don't restarted per se which means any class you use which might be "cached" somewhere (Facades, Singletons) are only created once and never again (until the service/worker restarts).

(for example: there or other Background job solutions for PHP which always fork a new worker process => that kind of architecture will not suffer this problem)

The benefit is increased overall performance because the framework is only bootstrapped once per worker and usually there's nothing which changes (unless you deploy, in which case you need to trigger the restart).

That said, this can catch especially PHP developers off guard which usually aren't used to this "longevity" of processes/classes/code and requires sometimes a different way of thinking how to solve things.

Btw, from your description it does not sound like you suffered the issues title problem ("Horizon restarting but old code is being used") and I think your explanation is clear that it's another matter (for which you found the correct solution, I believe).

[loshmis]

Of course @mfn, it is pretty clear that the issue is not what the title says as I thought initially, and since I already posted a comment about the issue, I added another comment for anyone with the similar issue.

[eKevinHoang]

@Braunson
Try with this command 'composer dumpautoload' everytime you deploy new source.
If you run horizon via supervisor, you must restart supervisor. 👯‍♂️

[Braunson]

@KevinHN I tried this and it didn’t work. Put everything on a new server and no more issues

[halaei]

One thing I do to check for old horizon processes is this command. It prints all the horizon processes sorted descending by start time. Kill the old ones and see if the error happens again.

ps -eo pid,lstart,cmd --sort -start_time|grep horizon

I think there has been some bug-fixes in the recent horizon versions that fixed this issue.
I don't use horizon:purge anymore because it interferes horizon of other projects on the same server.

[josegus]

@KevinHN I tried this and it didn’t work. Put everything on a new server and no more issues

This should be open, start all in a new server sometimes is not an option.