Abonelik Çift Sayım Bug Analizi

Subscription Chaining Sistemindeki Kritik Hata

📝 Basit Anlatım (Herkes İçin)

Ne Oluyor?

Bazı müşteriler ödeme yaptıklarında, sistemin hatalı çalışması nedeniyle ödediklerinden fazla gün alıyorlar.

Nasıl Oluyor?

Örnek: Cansu 24 Şubat'ta 30 günlük paket aldı (720 TL). Paketin süresi 27 Mart'ta bitti. 30 Mart'ta tekrar 30 günlük paket aldı (720 TL).

Olması gereken: 60 gün hak (2 × 30 gün)

Olan: ~90 gün hak (ilk 30 gün + yeni 30 gün + tekrar sayılan eski 30 gün)

Neden Önemli?

Son 60 günde 27 müşteri bu hatadan etkilendi.

Toplam ~3.739 gün fazla verildi = ~89.736 TL kayıp

40
Analiz Edilen
(2+ Ödeme Yapan)
27
Etkilenen Kullanıcı
(%67.5)
3.739
Fazla Verilen Gün
(~10.2 yıl!)
89.736₺
Tahmini Kayıp
(24₺/gün)

🔧 Teknik Detaylar (Geliştiriciler İçin)

Bug'ın Kök Nedeni

rechainUserSubscriptions() fonksiyonu, pending durumundaki abonelikleri yeni aktif aboneliğin arkasına zincirlerken, bu aboneliklerin süresinin daha önce subscription_expires_at üzerinden kullanılıp kullanılmadığını kontrol etmiyor.

Hatalı Akış Senaryosu

Tarih Olay subscription_expires_at Sorun
24 Şubat İlk ödeme (720₺) → Abonelik #4093 pending olarak oluştu 27 Mart -
25 Şubat #4093 aktif oldu (25 Şub → 27 Mart) 27 Mart -
27 Mart #4093 süresi doldu, expired olmalı 27 Mart (geçmiş) ⚠️ Kullanıcının artık erişimi yok
30 Mart İkinci ödeme (720₺) → Yeni #5459 active olarak oluştu 29 Nisan -
30 Mart rechainUserSubscriptions() çağrıldı → #4093 pending olarak zincirlendi (29 Nis → 29 May) 29 Mayıs! 🐛 #4093'ün 30 günü İKİ KEZ sayıldı!

İlgili Kod Dosyaları

BUG Modules/Subscription/App/Models/Subscription.php:370 → rechainUserSubscriptions()
RELATED Modules/Cart/App/Models/Order.php → activateSubscriptionItems()
RELATED app/Models/User.php → recalculateSubscriptionExpiry()

Çözüm Önerileri

ÖNERİ 1

Pending abonelik kullanılmışsa zincirleme

rechainUserSubscriptions() içinde, pending aboneliğin original_period_end tarihine bakılmalı. Eğer geçmişteyse, bu abonelik zaten "kullanılmış" demektir ve zincirlenmemeli.

ÖNERİ 2

Yeni alan: consumed_at

Abonelik tablosuna consumed_at alanı eklenip, abonelik süresi başladığında işaretlenebilir. Zincirleme sadece consumed_at = NULL olan aboneliklere uygulanır.

ÖNERİ 3

Status kontrolü

Pending dışındaki aboneliklerin zincirlenmemesi gerekiyor. Özellikle expired veya active status'teki aboneliklerin tarihleri güncellenmemeli.

Etkilenen Kullanıcılar (En Çok Fazla Alan)

Kullanıcı Beklenen Verilen Fazla Tahmini Kayıp
gülşen 395 gün 1.128 gün +719 gün ~17.256₺
mustafa 395 gün 829 gün +420 gün ~10.080₺
Ümit 60 gün 476 gün +402 gün ~9.648₺
WOLFBULLGYM 395 gün 800 gün +391 gün ~9.384₺
EFE 395 gün 763 gün +354 gün ~8.496₺
Etmanyak 395 gün 763 gün +354 gün ~8.496₺
kiraz 60 gün 333 gün +259 gün ~6.216₺
Cansu 60 gün 226 gün +152 gün ~3.648₺
... ve 19 kişi daha Toplam: +3.739 gün fazla verildi

Acil Aksiyon Gerekli

1

rechainUserSubscriptions() fonksiyonundaki bug düzeltilmeli (expired/kullanılmış abonelikleri zincirlememeli)

2

Etkilenen kullanıcıların subscription_expires_at değerleri manuel olarak düzeltilmeli (opsiyonel - karar sizin)

3

Yeni ödemeler yapılmadan önce bug'ın düzeltildiğinden emin olunmalı

31 Mart 2026 • Muzibu.com