<p>I recognised a strange behavior after upgrading laravel from 8 to 9. I have a scheduler that executes some jobs.</p>
<p>Kernel.php:</p>
<pre class="lang-php prettyprint-override"><code>$schedule-&gt;job(new ImportAzApplications, 'imports')
    -&gt;everyFiveMinutes()
    -&gt;onOneServer()
    -&gt;onFailure(function () {
        Log::error('Scheduled &quot;ImportAzApplications&quot; failed');
    });
$schedule-&gt;job(new ImportServicePrincipals, 'imports')
    -&gt;everyFiveMinutes()
    -&gt;onOneServer()
    -&gt;onFailure(function () {
        Log::error('Scheduled &quot;ImportServicePrincipals&quot; failed');
    });
</code></pre>
<p>The scheduler will be executed by an cron job in kubernetes. At the <code>artisan schedule:run</code> command will be executed every 5 seconds.</p>
<p>Logs:</p>
<pre><code>[2022-04-23T10:55:06+00:00] Running scheduled command: App\Jobs\ImportServicePrincipals
[2022-04-23T10:55:06+00:00] Running scheduled command: App\Jobs\ImportAzApplications
</code></pre>
<p>Now I would except having two jobs in the <code>imports</code> queue. And I do. But only on my dev machine, not on the staging server.</p>
<p>One of the Jobs look like this:</p>
<pre class="lang-php prettyprint-override"><code>class ImportAzApplications implements ShouldQueue, ShouldBeUnique
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    /**
     * Create a new job instance.
     *
     * @return void
     */
    public function __construct()
    {
    }

    /**
     * Execute the job.
     *
     * @return void
     */
    public function handle()
    {
        $instance = new AzureApplications();
        $params = $instance-&gt;azApplicationImportParams();
        try {
            $instance-&gt;import($params);
            Log::debug('ImportAzApplications: Processing AzureApplications::importAzApplications');
        } catch (Exception $exception) {
            Log::error('ImportAzApplications: '.$exception-&gt;getMessage(), $params);
        }
    }
}
</code></pre>
<ul>
<li>I enabled debug log-level to fetch debug logs</li>
<li>I run unit tests successfully local</li>
<li>I validated the scheduler workflow on the stating server with <code>artisan schedule:list', </code>artisan schedule:run', <code>artisan schedule:test</code> and `artisan queue:work --queue=imports'</li>
<li>I monitored the database online via <code>tinker</code>: <code>DB::table('jobs')-&gt;get()</code> and <code>DB::table('failed_jobs')-&gt;get()</code>. Both remains empty</li>
<li>I run the Jobs manually in tinker <code>(new ImportAzApplications)-&gt;handle()</code> successfully</li>
<li>I executed a different job (export task) in the same queue successfully</li>
</ul>
<p>I'm pretty sure it's a super simple thing that I can't see atm but for now I'm running out of ideas and hope someone has some further ideas</p>
<p>Many thanks</p>
<h1>Edited</h1>
<p>during the weekend, some magic happened and the jobs where executed according to the new logs. I'm going to investigate the voodoo-magic further on kubernetes.</p>

<p>I have to excuse myself to the community. The Problem was actually caused by an pipeline workflow.</p>
<p>I run <code>laravel</code> on <code>kubernetes</code>. There're multiple pod for different exercises available.</p>
<h2><code>app</code></h2>
<p>the actual laraval application</p>
<h2><code>queue</code></h2>
<p>the same container image with a slide different configuration to process the jobs in the queues using the <code>php artisan queue:work --queue=imports</code> command</p>
<h2><code>jobs</code></h2>
<p>a kubernetes job that executes scheduled jobs using the <code>php artisan schedule:run</code> command defined in the <code>App\Console\Kernel</code> every minute</p>
<p>Once a new release will be pushed to the registry, a <code>kubectl set env</code> command sets the new build version which forces the <code>app</code> Pod to grab a new container image. This is defined the kubernetes strategy.</p>
<p>However the <code>queue</code> run with the old image. I've forced the <code>queue</code> to get latest image (no voodoo-magic) and the jobs where executed.</p>
<p>Thanks for all that who took there time to investigate and try to reproduce this beavure. That wasn't easy.</p>
<p>Cheers!</p>
