Laravel’de bir job dispatch edildiğinde herhangi bir hata alınmaması, o işin gerçekten çalıştığı anlamına gelmiyor.

Kod tarafında job başarıyla kuyruğa gönderilebilir. Kayıt jobs tablosunda görünebilir. Kullanıcı formu gönderir ve uygulama normal cevabını döndürür. Buna rağmen e-posta gitmez, görsel işlenmez veya arka planda yapılması gereken işlem hiç başlamaz.

Bu durumda sorun job sınıfında olabilir. Queue bağlantısı yanlış olabilir. Worker farklı kuyruğu dinliyor olabilir. Supervisor yanlış PHP sürümünü kullanıyor olabilir. Hatta her şey doğru olduğu hâlde deploy sonrasında worker eski kodla çalışmaya devam ediyor olabilir.

“Queue çalışmıyor” tek bir hata değil. Aynı belirtiyi oluşturan birkaç farklı sorunun genel adı.

Bu nedenle Supervisor yapılandırmasını hemen değiştirmek veya servisi sürekli yeniden başlatmak yerine önce işin hangi aşamada kaldığını bulmak gerekiyor.

Önce Job Gerçekten Kuyruğa Giriyor mu?

İlk ayrım burada yapılmalı.

Job dispatch ediliyor ama kuyruğa hiç yazılmıyorsa Supervisor’a bakmanın bir anlamı yok. Supervisor yalnızca kuyrukta bulunan işleri çalıştırabilir. Uygulamanın kuyruğa gönderemediği bir işi düzeltemez.

İlk olarak aktif queue bağlantısını kontrol edelim:

QUEUE_CONNECTION=database

Redis kullanılıyorsa değer buna göre değişebilir:

QUEUE_CONNECTION=redis

Burada dikkat edilmesi gereken nokta yalnızca .env dosyasındaki değer değil. Laravel daha önce cache’lenmiş yapılandırmayı kullanıyor olabilir.

.env içinde database yazmasına rağmen uygulama eski sync değerini kullanıyorsa değişiklik beklediğimiz sonucu vermez.

Aktif değeri Tinker üzerinden kontrol edebiliriz:

php artisan tinker

Ardından:

config('queue.default');

Beklediğimiz bağlantı görünmüyorsa yapılandırma cache’ini temizleyip yeniden oluşturabiliriz:

php artisan config:clear
php artisan config:cache

config:cache kullanıldığında uygulama içinde doğrudan env() çağırmamak gerekir. Ortam değişkenleri config dosyalarında tanımlanmalı, uygulamanın diğer bölümlerinde config() üzerinden okunmalıdır.

Örneğin queue bağlantısını bir servis veya job içinde şu şekilde kontrol etmek doğru olmaz:

env('QUEUE_CONNECTION');

Bunun yerine:

config('queue.default');

kullanılmalıdır.

Eğer database bağlantısı kullanılıyorsa gerekli queue tablolarının da veritabanında bulunması gerekir. Projede migration yoksa oluşturulabilir:

php artisan make:queue-table
php artisan make:queue-failed-table
php artisan migrate

Kullanılan Laravel sürümüne ve projenin mevcut migration yapısına göre bu tablolardan bazıları zaten bulunabilir. Aynı migration’ı tekrar üretmeden önce database/migrations dizinini ve veritabanını kontrol etmek daha doğru olur.

Job dispatch edildikten sonra jobs tablosunda yeni kayıt oluşuyorsa uygulama işi kuyruğa gönderebiliyor demektir.

Artık sorunun bir sonraki aşamasına geçebiliriz.

sync Kullanılıyorsa Ortada Gerçek Bir Queue Yoktur

Yerel geliştirme sırasında QUEUE_CONNECTION=sync kullanmak işleri kolaylaştırabilir.

Bu bağlantıda dispatch edilen job ayrı bir worker tarafından işlenmez. Job, mevcut web isteğinin içinde anında çalıştırılır.

Bu nedenle yerelde çalışan bir job canlı ortamda database veya redis bağlantısına geçildiğinde durabilir. Kod değişmemiştir ama çalışma şekli değişmiştir.

sync bağlantısında şu kod hemen çalışır:

ProcessImages::dispatch($image);

database bağlantısında ise bu kod yalnızca işi kuyruğa ekler. İşin tamamlanması için ayrıca bir worker’ın çalışması gerekir.

Bu ayrım bazen gözden kaçıyor. Yerelde job’ın başarılı olması, queue altyapısının test edildiği anlamına gelmiyor. Yalnızca job kodunun aynı istek içinde çalışabildiğini gösteriyor.

Queue sürecini gerçekten test etmek için yerel ortamda da geçici olarak database veya kullanılan diğer bağlantıya geçilebilir. Böylece job’ın serileştirilmesi, kuyruğa yazılması ve worker tarafından yeniden yüklenmesi sırasında oluşabilecek hatalar daha erken görülür.

Worker’ı Önce Elle Çalıştırın

Job jobs tablosuna yazılıyor ama işlenmiyorsa Supervisor’a geçmeden önce worker’ı terminalde elle çalıştırmak gerekir.

Proje dizinine girelim:

cd /home/kullanici/public_html

Laravel’in artisan dosyasının bulunduğu gerçek dizin neyse oraya geçilmelidir. Bazı cPanel kurulumlarında domainin DocumentRoot değeri public_html/public olabilir ama artisan dosyası bir üst dizinde bulunur.

Ardından worker’ı çalıştıralım:

php artisan queue:work --verbose

Yalnızca bir işi çalıştırıp sürecin kapanmasını istiyorsak:

php artisan queue:work --once --verbose

Belirli bir bağlantıyı test etmek için:

php artisan queue:work database --verbose

Belirli bir kuyruğu dinlemek için:

php artisan queue:work database --queue=emails --verbose

Worker terminalde çalıştığında bekleyen job tamamlanıyorsa job sınıfı ve queue bağlantısı büyük ölçüde çalışıyor demektir. Sorun muhtemelen Supervisor’ın worker’ı hiç başlatmaması, yanlış komutla başlatması veya sürecin sonlanmasıdır.

Worker elle çalıştırıldığında hata veriyorsa önce bu hatayı çözmek gerekir. Supervisor aynı komutu arka planda çalıştıracağı için elle başarısız olan bir worker’ın Supervisor altında başarılı olmasını bekleyemeyiz.

Bu test, sorunun kodda mı yoksa süreç yönetiminde mi olduğunu ayıran en kısa yollardan biridir.

Job Başarısız mı Oluyor, Hiç Başlamıyor mu?

Worker çalışıyor görünmesine rağmen işlem tamamlanmıyorsa failed_jobs kayıtlarına bakılmalıdır.

php artisan queue:failed

Başarısız job’ın ayrıntıları veritabanındaki failed_jobs tablosundan veya uygulama loglarından incelenebilir:

tail -f storage/logs/laravel.log

Belirli bir başarısız job yeniden denenebilir:

php artisan queue:retry JOB_UUID

Bütün başarısız işler yeniden denenmek istenirse:

php artisan queue:retry all

Fakat hatanın nedeni çözülmeden bütün işleri tekrar kuyruğa göndermek yalnızca aynı hataların yeniden oluşmasına neden olur.

Başarısız job’larda sık karşılaşılan sorunlardan bazıları şunlardır:

  • Job içine serileştirilemeyen bir nesne gönderilmesi

  • Model veya kaydın worker çalışana kadar silinmiş olması

  • Gerekli dosyanın artık bulunmaması

  • Dosya izinlerinin worker kullanıcısına uygun olmaması

  • Harici API isteğinin timeout olması

  • E-posta yapılandırmasının eksik veya cache’te eski kalması

  • Job çalışırken bellek sınırının aşılması

  • Worker’ın web sitesinden farklı PHP sürümüyle çalışması

  • Job süresinin worker timeout değerini geçmesi

Worker’ın hiç başlamamasıyla job’ın başlayıp hata vermesi farklı sorunlardır. jobs tablosundaki kayıt sürekli duruyorsa worker o kuyruğu almıyor olabilir. Kayıt kaybolup failed_jobs tablosuna geçiyorsa worker işi almış ancak tamamlayamamıştır.

Bu ayrım teşhisi ciddi biçimde hızlandırır.

Supervisor Gerçekten Çalışıyor mu?

Worker terminalde sorunsuz çalışıyorsa artık Supervisor tarafına bakabiliriz.

Önce servisin durumunu kontrol etmek gerekir. Dağıtıma göre servis adı değişebilir:

systemctl status supervisor

veya:

systemctl status supervisord

Supervisor’ın yönettiği süreçleri görmek için:

supervisorctl status

Çıktıda worker şu durumlardan birinde olabilir:

  • RUNNING: Süreç çalışıyor.

  • STOPPED: Süreç durdurulmuş.

  • STARTING: Başlatılmaya çalışılıyor.

  • BACKOFF: Başlatıldıktan kısa süre sonra kapanıyor.

  • FATAL: Birkaç denemenin ardından başlatılamamış.

  • EXITED: Süreç çalışmış ancak sonlanmış.

RUNNING görünmesi tek başına job’ların işlendiğini garanti etmez. Worker yanlış proje dizininde, yanlış PHP binary’siyle veya farklı queue adıyla çalışıyor olabilir.

BACKOFF ve FATAL durumları ise çoğu zaman command, directory, user, dosya izinleri veya log yolu sorunlarına işaret eder.

Supervisor belgelerinde startretries, başlangıç sırasında başarısız olan sürecin kaç kez yeniden deneneceğini; autorestart ise çalışır duruma geldikten sonra kapanan sürecin yeniden başlatılıp başlatılmayacağını belirler. Supervisor yapılandırma belgeleri

Supervisor Dosyası Nerede?

Supervisor yapılandırma dizini işletim sistemine ve kurulum yöntemine göre değişebilir.

Ubuntu sistemlerde sık kullanılan konum:

/etc/supervisor/conf.d/

cPanel, CloudLinux veya bazı RHEL tabanlı sistemlerde ise şu dizin görülebilir:

/etc/supervisord.d/

Dosya uzantısı da kurulum yapısına göre .conf veya .ini olabilir.

Mevcut yapılandırmanın hangi dosyaları dahil ettiğini görmek için ana Supervisor yapılandırması kontrol edilebilir:

supervisord -c /etc/supervisord.conf -n

Bu komut Supervisor’ı ön planda başlatmaya çalışacağı için çalışan production sisteminde doğrudan kullanılmamalıdır. Yapılandırma konumunu bulmak için daha güvenli olarak süreç argümanlarına veya servis tanımına bakılabilir:

ps aux | grep supervisord
systemctl cat supervisord

Ayrıca muhtemel dizinler listelenebilir:

find /etc -maxdepth 3 \
-type f \( -name "*.conf" -o -name "*.ini" \) \
2>/dev/null | grep -i supervisor

Yeni yapılandırma dosyasını rastgele bir dizine eklemek yeterli değildir. O dizinin ana Supervisor dosyasındaki [include] bölümüne gerçekten dahil edildiğinden emin olmak gerekir.

Doğru Bir Supervisor Yapılandırması Nasıl Görünür?

Genel bir Laravel worker yapılandırması şu şekilde olabilir:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=/usr/bin/php /home/kullanici/public_html/artisan queue:work database --sleep=3 --tries=3 --timeout=90
directory=/home/kullanici/public_html
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=kullanici
numprocs=1
redirect_stderr=true
stdout_logfile=/home/kullanici/public_html/storage/logs/worker.log
stopwaitsecs=120

Bu dosya doğrudan kopyalanıp kullanılmamalı. Proje dizini, PHP yolu, kullanıcı, queue bağlantısı, timeout ve log yolu sunucuya göre değiştirilmelidir.

Özellikle şu satırlar kontrol edilmelidir:

command=/usr/bin/php /home/kullanici/public_html/artisan queue:work
directory=/home/kullanici/public_html
user=kullanici
stdout_logfile=/home/kullanici/public_html/storage/logs/worker.log

Supervisor root olarak çalışıyor olsa bile worker’ı web sitesinin dosya sahibi olan kullanıcıyla çalıştırmak daha doğru olur. Worker’ın root kullanıcısıyla oluşturduğu cache, log veya işlenmiş dosyalar daha sonra web kullanıcısı tarafından değiştirilemeyebilir.

Ayrıca birden fazla worker aynı dönen log dosyasını paylaşacaksa Supervisor’ın log rotasyonu davranışı ayrıca değerlendirilmelidir. Supervisor belgeleri, birden fazla sürecin aynı rotating log dosyasına yazmasının bozulmaya yol açabileceği konusunda uyarıyor.

En Sık Hata: Yanlış PHP Binary’si

Terminalde yalnızca şu komutu çalıştırdığımızda:

which php

örneğin şu yol dönebilir:

/usr/bin/php

Fakat web sitesi bu PHP sürümünü kullanmıyor olabilir.

cPanel EA-PHP kurulumunda PHP yolu sürüme göre şu yapıda olabilir:

/opt/cpanel/ea-php83/root/usr/bin/php

CloudLinux Alt-PHP tarafında ise şöyle bir yol kullanılabilir:

/opt/alt/php85/usr/bin/php

Bu yollar yalnızca örnektir. Sunucudaki gerçek yol mutlaka kontrol edilmelidir.

Mevcut PHP binary’leri şu şekilde aranabilir:

find /opt -type f -path "*/usr/bin/php" 2>/dev/null

Belirli bir PHP sürümünü doğrulamak için:

/opt/cpanel/ea-php83/root/usr/bin/php -v

veya:

/opt/alt/php85/usr/bin/php -v

Supervisor yapılandırmasındaki command satırında doğru PHP binary’si açıkça yazılmalıdır:

command=/opt/cpanel/ea-php83/root/usr/bin/php /home/kullanici/public_html/artisan queue:work database --sleep=3 --tries=3 --timeout=90

Web sitesi PHP 8.3 ile çalışırken worker PHP 8.1 kullanıyorsa paket uyumsuzluğu, eksik extension veya syntax hatası oluşabilir. Worker hiç başlayamayabilir ya da belirli job’larda beklenmeyen hatalar verebilir.

CLI tarafında gereken extension’ların etkin olması da önemlidir. Web PHP’sinde bulunan intl, gd, imagick, redis veya başka bir extension, Supervisor’ın kullandığı CLI PHP’de bulunmayabilir.

Kontrol için:

/PHP/YOLU/php -m

kullanılabilir.

Web sitesinin çalışıyor olması, Supervisor’ın kullandığı PHP ortamının da doğru olduğu anlamına gelmez.

Supervisor Değişikliği Neden Uygulanmıyor?

Yapılandırma dosyasını düzenledikten sonra yalnızca servisin açık olması yeterli değildir. Supervisor’a dosyaları yeniden okutmak gerekir.

supervisorctl reread

Ardından değişiklikleri uygulayalım:

supervisorctl update

Son durumu kontrol edelim:

supervisorctl status

Belirli bir worker yeniden başlatılabilir:

supervisorctl restart laravel-worker:*

Program adı farklıysa komut buna göre düzenlenmelidir.

reread, yeni veya değişen yapılandırmaları algılar. update, eklenen ve kaldırılan program gruplarını uygular. Yalnızca restart çalıştırmak, Supervisor’ın eski yapılandırmayı kullanmaya devam etmesine neden olabilir.

Bu nedenle yapılandırma değişikliğinden sonra doğru sıra genellikle şöyledir:

supervisorctl reread
supervisorctl update
supervisorctl restart laravel-worker:*
supervisorctl status

Eğer reread sonrasında “No config updates” çıktısı alınıyorsa düzenlenen dosya Supervisor tarafından dahil edilmiyor olabilir veya değişiklik algılanmamış olabilir.

Worker Çalışıyor ama Yanlış Kuyruğu Dinliyor Olabilir

Laravel’de bir job belirli bir kuyruğa gönderilebilir:

SendCampaignEmail::dispatch($campaign)
    ->onQueue('emails');

Supervisor yalnızca varsayılan kuyruğu dinliyorsa emails kuyruğundaki işler bekleyebilir.

Worker komutunda kuyruk açıkça belirtilebilir:

php artisan queue:work redis --queue=emails,default

Kuyruk sıralaması da önemlidir. Bu komutta worker önce emails, ardından default kuyruğundaki işleri işler.

Supervisor yapılandırmasına karşılığı şöyle eklenebilir:

command=/usr/bin/php /proje/artisan queue:work redis --queue=emails,default --sleep=3 --tries=3

Başka bir ihtimal, job’ın database bağlantısına gönderilmesi ancak worker’ın redis bağlantısını dinlemesidir:

ProcessReport::dispatch($report)
    ->onConnection('database');

Bu durumda Redis worker ne kadar sağlıklı çalışırsa çalışsın ilgili job’ı görmez.

Job’ın gönderildiği bağlantı ve kuyrukla worker’ın dinlediği bağlantı ve kuyruk aynı olmalıdır.

Worker Neden Eski Kodu Çalıştırıyor?

queue:work uzun süre çalışan bir süreçtir. Uygulama her job’da tamamen yeniden başlatılmaz.

Bu nedenle deploy sırasında dosyalar güncellense bile mevcut worker bellekte yüklediği eski kodla çalışmaya devam edebilir. Job sınıfında yapılan değişiklikler uygulanmaz, eski servis ayarları kullanılabilir veya artık bulunmayan bir sınıf çağrılabilir.

Deploy sonrasında şu komut çalıştırılmalıdır:

php artisan queue:restart

Bu komut çalışan worker’lara mevcut job tamamlandıktan sonra güvenli biçimde kapanmaları gerektiğini bildirir. Supervisor yapılandırmasında autorestart=true olduğu için kapanan worker yeniden başlatılır ve yeni kodu yükler.

Laravel’in resmi belgelerinde de queue worker’ların uzun süre yaşayan süreçler olduğu ve deploy sırasında yeniden başlatılması gerektiği belirtiliyor. Laravel queue dokümantasyonu

queue:restart çalıştırıldığı hâlde worker kapanmıyorsa uygulamanın cache bağlantısı kontrol edilmelidir. Restart sinyali cache üzerinden iletilir. Web uygulamasıyla worker farklı cache yapılandırması kullanıyorsa veya cache dizininde izin sorunu varsa sinyal worker’a ulaşmayabilir.

Gerekirse Supervisor üzerinden doğrudan yeniden başlatma yapılabilir:

supervisorctl restart laravel-worker:*

Ancak çalışan uzun bir job varsa sert yeniden başlatma işlemin yarıda kalmasına neden olabilir. Bu nedenle deploy akışında önce queue:restart kullanmak daha kontrollü bir yöntemdir.

timeout ve retry_after Birbirine Karıştırılmamalı

Uzun süren job’larda worker’ın sürekli kapanması veya aynı job’ın iki kez işlenmesi görülebilir.

Queue worker şu şekilde çalıştırılmış olabilir:

php artisan queue:work --timeout=90

Buradaki timeout, worker’ın bir job’a en fazla kaç saniye izin vereceğini belirler.

Queue bağlantısındaki retry_after ise işlenen ancak tamamlandığı bilgisi alınmayan job’ın kaç saniye sonra tekrar kuyruğa uygun hâle geleceğini belirler.

Laravel belgelerine göre --timeout değeri, retry_after değerinden birkaç saniye daha kısa olmalıdır. Aksi hâlde aynı job’ın ikinci kez işlenmeye başlaması mümkündür.

Örneğin:

// config/queue.php

'retry_after' => 120,

Worker komutu:

php artisan queue:work --timeout=90

Bu yapı, worker’ın 90 saniyede job’ı sonlandırmasına ve job yeniden görünür olmadan önce sürecin kapanmasına zaman tanır.

Supervisor tarafındaki stopwaitsecs değeri de en uzun job’ın tamamlanabilmesi için yeterli olmalıdır:

stopwaitsecs=120

Eğer bazı raporlar 10 dakika sürüyorsa 120 saniye yeterli değildir. Ancak çözüm yalnızca timeout değerlerini sürekli yükseltmek de olmayabilir. Uzun işlem daha küçük job’lara bölünebilir veya toplu veri işleme yöntemi yeniden değerlendirilebilir.

Dosya İzinleri Queue’yu Sessizce Durdurabilir

Web uygulaması ile worker farklı kullanıcılarla çalışıyorsa dosya izinleri sorun çıkarabilir.

Worker şu alanlara yazabilmelidir:

storage/
bootstrap/cache/

Görsel işleyen veya dosya oluşturan job’larda ilgili disk dizinlerine de erişim gerekir.

İzinleri kontrol etmek için:

ls -ld storage bootstrap/cache

Log dosyasının sahibi ve izinleri de incelenebilir:

ls -la storage/logs

Supervisor yapılandırmasında tanımlanan log dosyasının bulunduğu dizin yoksa veya worker kullanıcısı bu dizine yazamıyorsa süreç başlatılamayabilir.

İlk refleks olarak bütün projeye 777 vermek doğru bir çözüm değildir. Dosya sahibi, web sunucusu kullanıcısı ve Supervisor’daki user değeri birlikte değerlendirilmelidir.

Worker’ı proje sahibi kullanıcıyla çalıştırmak, storage ve bootstrap/cache dizinlerine gerekli grup izinlerini vermek çoğu durumda daha sağlıklı bir yapı oluşturur.

Loglara Bakmadan Supervisor Sorunu Çözülmez

supervisorctl status yalnızca sürecin mevcut durumunu gösterir. Neden durduğunu her zaman açıklamaz.

Supervisor servis logları dağıtıma göre farklı konumlarda olabilir:

/var/log/supervisor/supervisord.log

veya:

/var/log/supervisord.log

Servis logları journalctl üzerinden de incelenebilir:

journalctl -u supervisord -n 100 --no-pager

veya:

journalctl -u supervisor -n 100 --no-pager

Worker için tanımlanan özel log da takip edilmelidir:

tail -f /home/kullanici/public_html/storage/logs/worker.log

Laravel logu ayrı olarak izlenebilir:

tail -f /home/kullanici/public_html/storage/logs/laravel.log

Burada aranabilecek hatalar oldukça nettir:

  • command not found

  • can't find command

  • permission denied

  • directory does not exist

  • spawn error

  • exit status 1

  • PHP syntax veya extension hataları

  • Veritabanı bağlantı hataları

  • Log dosyasına yazma hataları

  • Bellek sınırı veya timeout hataları

Logda Could not open input file: artisan görülüyorsa proje yolu yanlıştır. Permission denied görülüyorsa kullanıcı ve izinler kontrol edilmelidir. PHP sınıf veya paket hatası varsa Supervisor’ın kullandığı PHP sürümü incelenmelidir.

Tahmin yürütmek yerine logdaki ilk gerçek hatadan ilerlemek çoğu zaman en kısa yoldur.

Queue Sorununda İzlenecek Teşhis Sırası

Queue çalışmadığında bütün ayarları aynı anda değiştirmek yerine şu sırayla ilerlemek daha sağlıklıdır:

  1. Aktif bağlantıyı kontrol edin: config('queue.default') beklenen değeri döndürüyor mu?

  2. Job’ın kuyruğa girdiğini doğrulayın: jobs tablosunda veya Redis kuyruğunda kayıt oluşuyor mu?

  3. Worker’ı terminalde çalıştırın: Job elle başlatılan worker ile tamamlanıyor mu?

  4. Başarısız işleri inceleyin: php artisan queue:failed çıktısında kayıt var mı?

  5. Bağlantı ve queue adını karşılaştırın: Job ile worker aynı bağlantı ve kuyruğu mu kullanıyor?

  6. PHP binary’sini doğrulayın: Supervisor sitenin çalıştığı PHP sürümünü mü kullanıyor?

  7. Supervisor durumuna bakın: Süreç RUNNING, BACKOFF veya FATAL mı?

  8. Logları okuyun: Laravel, worker ve Supervisor loglarında ilk gerçek hata ne?

  9. Dosya izinlerini kontrol edin: Worker gerekli dizinlere yazabiliyor mu?

  10. Deploy sonrasında worker’ı yenileyin: queue:restart veya kontrollü Supervisor restart işlemi uygulandı mı?

Bu sıra, sorunu kod, Laravel yapılandırması ve sunucu süreci olarak ayırır. Job terminalde bile çalışmıyorsa Supervisor dosyasıyla uğraşmak vakit kaybettirir. Terminalde çalışıyor ancak Supervisor altında başlamıyorsa odağı süreç yönetimine çevirmek gerekir.

Worker Çalışmadan Queue Çalışmış Sayılmaz

Laravel tarafında job sınıfını hazırlamak ve dispatch() çağrısını yapmak queue sisteminin yalnızca ilk yarısıdır.

İkinci yarıda işi alacak bir worker, worker’ı ayakta tutacak Supervisor, doğru PHP binary’si, doğru proje dizini, uygun kullanıcı izinleri ve takip edilebilir loglar bulunmalıdır.

Bu zincirin herhangi bir noktası koptuğunda uygulama çoğu zaman hata göstermeden normal şekilde çalışmaya devam eder. Kullanıcı formu gönderir, “İşleminiz alındı” mesajını görür ama arka plandaki görev hiçbir zaman tamamlanmaz.

Bu nedenle queue sorunlarında yalnızca koda veya yalnızca Supervisor’a bakmak yeterli değildir. Önce job’ın kuyruğa girdiğini, ardından worker’ın onu gerçekten aldığını ve son olarak işlemin başarıyla tamamlandığını doğrulamak gerekir.

Queue’nun çalıştığını gösteren şey dispatch() satırının hata vermemesi değil, işin baştan sona tamamlanmasıdır.