Django 6.0'ın Tasks API'sı worker olmadan geliyor, Celery göç planlarını zorlaştırıyor

Django motoru değil, arayüzü teslim ediyor

3 Aralık 2025'te yayımlanan Django 6.0, arka plan işleri için yerleşik bir Tasks çerçevesi içeriyor ve dev.to'daki uygulamalı bir yükseltme raporuna göre en kritik ayrıntı, çerçevenin neyi dışarıda bıraktığı. Django'nun kendi belgeleri, çerçevenin görevleri çalıştırma mekanizması içermediğini açıkça belirtiyor; yürütmenin Django'nun dışında ayrı bir süreç veya servis tarafından ele alınması gerekiyor.

API yüzeyi kompakt: bir fonksiyon @task dekoratörüyle işaretleniyor, isteğe bağlı olarak bir kuyruk adı ve öncelik veriliyor ve .enqueue() çağrısıyla kuyruğa alınıyor; bu çağrı bir TaskResult döndürüyor. Backend'ler TASKS ayar bloğu üzerinden yapılandırılıyor; bu, DATABASES ve CACHES örüntüsünü yansıtıyor.

Kutuyla birlikte iki backend geliyor. ImmediateBackend fonksiyonu kuyruğa alındığı anda satır içi çalıştırıyor; DummyBackend ise sonucu kaydediyor ve hiçbir şey çalıştırmıyor. Dev.to raporu, Django'nun referans belgelerinin ikisini de geliştirme ve test araçları olarak tanımladığına ve üretim dağıtımlarını bir worker süreci ve kalıcı bir kuyruk sunan backend'lere yönlendirdiğine dikkat çekiyor.

Üretim düzeyi bir kuyruğun dolduracağı boşluklar

Gerçek arka plan altyapısının ihtiyaçlarıyla karşılaştırıldığında çerçeve bilinçli olarak eksik. Rapor eksik olanları sıralıyor: worker yok, tekrar deneme politikası yok (istisna fırlatan bir görev, istisnasını ve traceback'ini TaskResult.errors içine kaydediyor ve sonra duruyor), periyodik zamanlama yok, dead-letter kuyruğu yok, eşzamanlılık denetimleri yok ve seçilen backend sağlamadığı sürece kalıcı depolama yok.

run_after seçeneği bir timedelta veya saat dilimi farkında bir datetime kabul ediyor ve backend'ler supports_defer, supports_priority ve supports_get_result gibi yetenek bayraklarıyla neyi desteklediklerini duyuruyor. Yazar, tek seferlik bir gecikmenin faydalı olduğunu, ancak cron'un yerini tutmadığını belirtiyor.

Kapsam bilinçliydi. Çerçeve, Jake Howard tarafından yazılan ve Django'da uzun süreli arka plan görevleri için bir arayüz ve temel uygulama sağlamayı hedefleyen DEP 14'ü izliyor. Arayüz Eylül 2025'te çekirdeğe girdi ve 6.0 ile birlikte yayımlandı. Bir sonraki sürüm de boşluğu kapatmadı: rapora göre Django 6.1 dekoratöre bir kwargs geçişi ekledi ve Task ile TaskResult'ı picklable yaptı, ancak veritabanı backend'i, worker komutu ve yeniden deneme desteği getirmedi.

Ekiplerin arayüzün arkasına koyduğu şeyler

Rapor üç yürütme seçeneğini tartıyor:

• django_tasks_db'nin DatabaseBackend'i görevleri veritabanı satırları olarak saklıyor, bir db_worker yönetim komutu ve bir temizleme komutuyla geliyor ve zamanlanmış, tamamlanmış ve hatalı görevleri Django admin'de görünür kılıyor. Ödünleşim çekişme: her kuyruğa alma bir yazma ve her yoklama, web isteklerine hizmet veren aynı veritabanına yapılan bir sorgu oluyor.
• Celery, bir broker'ın zaten dağıtılmış olduğu yerlerde cazibesini koruyor; zira geri çekilmeli yeniden denemeler, beat zamanlaması, yönlendirme, hız sınırları ve akorlar sunmaya devam ediyor ve bunların hiçbirini Django arayüzünün büyüyerek kapsaması planlanmıyor.
• RQ ikisinin arasında duruyor: Redis tabanlı ve Celery'den çok daha hafif; veritabanı yoklamasını aşmış ama iş akışı ilkellerine ihtiyaç duymayan servisler için uygun.

Yazarın bir uyumluluk SaaS projesindeki kendi sonucu şöyle oldu: yeniden deneme ve zamanlama gerektiren senkronizasyon işleri için Celery yerinde kaldı, iki fire-and-forget e-posta yolu ise veritabanı backend'i üzerindeki yeni API'ye taşındı — başta planlanan tam Celery kaldırması değil, artımlı bir geçiş.

API'nin çözmediği iki tuzak

transaction.atomic() içinde kuyruğa alma bilinen bir başarısızlık biçimi olmayı sürdürüyor: farklı bir bağlantıdaki worker, işlem commit edilmeden bir işi alabilir ve ihtiyaç duyduğu satırı bulamayabilir. Django'nun belgeleri, enqueue çağrısının functools.partial kullanılarak transaction.on_commit ile sarmalanmasını öneriyor. Celery kullanıcıları, Celery 5.4'te eklenen delay_on_commit() ile bir kısayol elde ediyor; ancak işlem bitene kadar broker'a hiçbir şey ulaşmadığı için bu yöntem bir görev kimliği döndürmüyor; Django arayüzünün buna eşdeğeri yok.

Görev argümanları ve dönüş değerleri JSON'a serileştiriliyor; dolayısıyla bir datetime nesnesi geçirmek TypeError fırlatıyor. Önerilen örüntü, birincil anahtarlar ve ISO biçimli dizeler geçirmek ve nesneyi görev içinde yeniden getirmek.

Neden önemli

6.0 yükseltmesinin Celery'yi bir öğleden sonrada silinebilir kılacağını bekleyen ekipler için sonuç şu: sorunun yürütme yarısını finanse etmek ve işletmek hâlâ onların sorumluluğunda. Rapor yine de arayüzün benimsenmeye değer olduğunu iki gerekçeyle savunuyor: uygulama kodu kuyruk sağlayıcısını adlandırmayı bırakıyor ve testler TASKS'ı DummyBackend'e yönlendirerek kuyruğa alınan görevleri broker, eager-mode bayrağı veya mock'lanmış çağrı olmadan doğrulayabiliyor. Veritabanı backend'ini daha sonra Redis tabanlı bir backend'le değiştirmek, yeniden yazım değil, bir ayar değişikliği artı bir worker süreci oluyor. Mevcut çoğu proje için gerçekçi yol artımlı: arayüzü işe yaradığı yerde benimsemek ve Celery'yi yeniden denemelerin ve zamanlamanın hakkını verdiği yerde tutmak.