Sitenin yayınlama platformunda çalışan bir temizlik betiği, kod parçacıklarını yanlışlıkla hatalı Liquid değişkenleri olarak tanımladı ve bunları içeren her makaleden sildi. Bu aksaklık, düzinelerce teknik yazıyı okuyucuların güvendiği örnek kodlardan yoksun bıraktı; bu da acil bir geri alma işlemi yapılmasına ve içerik taşıma süreçlerinin nasıl test edildiğinin yeniden düşünülmesine neden oldu.
Hatanın nasıl gözden kaçtığı
Platform, dinamik içeriği {{ … }} gibi etiketlerle işaretleyen bir şablon dili olan Liquid'i kullanıyor. Rutin bir bakım görevinin, işleme sürecini bozabilecek hatalı etiketleri temizlemesi gerekiyordu. Betiğin ayrıştırıcısı, eşleşen bir kapatma etiketi olmayan açılış etiketlerini aradı ve bir tane bulduğunda, hatayı "düzeltmek" amacıyla tüm bloğu sildi.
Uygulamada ayrıştırıcı, kod bloklarını sarmalayan {% raw %} ve {% endraw %} etiketlerini tanımayı başaramadı. Bu etiketler Liquid'e içerideki her şeyi düz metin olarak işlemesini söyler; ancak hatalı betik, açılış {% raw %} etiketini kapatılmamış bir değişken ({{% raw %}) olarak algıladı ve çevresindeki kodu kaldırdı. Kaydedilen hata mesajı şuydu:
Liquid syntax error: Variable '{{% raw %}' was not properly terminated.
Betik canlı içerik deposu üzerinde çalıştığı için silme işlemi toplu halde gerçekleşti ve tek bir seferde etkilenen tüm makalelerdeki kod örneklerini temizledi.
Riskler neler?
Teknik makaleler; kavramları açıklamak, sonuçları yeniden üretmek ve okuyuculara adım adım prosedürlerde rehberlik etmek için kod parçacıklarına ihtiyaç duyar. Bu blokların kaybı, yazıları büyük ölçüde işlevsiz hale getirir, yazarları içeriği yeniden yazmaya zorlar ve platformun güvenilirliğine olan güveni sarsar. İtibarını yüksek kaliteli geliştirici dokümantasyonu üzerine inşa eden bir site için bu olay, hem okuyucu kitlesini hem de katılımcıların iyi niyetini tehdit etmektedir.
Çoğu okuyucunun gözden kaçırdığı detaylar
- Kum havuzu (sandboxing) olmadan toplu işleme – Betik, bir hazırlık (staging) kopyası yerine doğrudan canlı veriler üzerinde çalıştırıldı.
- Yetersiz etiket yönetimi – Sadece bir grup Liquid etiketi dikkate alındı;
{% raw %}beyaz listeye dahil edilmedi. - Kademeli test eksikliği – Görev, küçük bir örneklem üzerinde pilot uygulama yapılmadan tüm veri seti üzerinde devreye alındı.
Neler önleyebilirdi?
- Taşıma işlemlerini bir kopya üzerinde çalıştırın – Herhangi bir toplu dönüşümü önce veritabanının kum havuzu (sandboxed) sürümüne uygulayın.
- Ayrıştırıcıları tüm etiket varyasyonlarına karşı birim testinden geçirin – Raw blokları, yorum etiketleri ve iç içe geçmiş yapılar gibi uç durumları (edge cases) dahil edin.
- Kademeli yaygınlaştırma – Sınırlı sayıda makaleyi işleyin, sonuçları doğrulayın ve ardından ölçeği artırın.
Karşı görüş
Bazıları, hızlı hareket eden siteler için her betiği tam bir yedek üzerinde test etmenin pratik olmadığını ve veri kaybı riskinin, hızlı düzeltme ihtiyacının gerisinde kaldığını savunuyor. Hız önemli olsa da, toplu bir silme işlemini geri almanın maliyeti –hem geliştirici zamanı hem de itibar kaybı açısından– genellikle temkinli bir yaygınlaştırmanın getireceği gecikmeden daha fazladır.
Bundan sonra neye dikkat edilmeli?
Ekip, eksik kodları yedeklerden geri yükledi ve temizlik aracını tüm Liquid yapılarını tanıyacak şekilde revize ediyor. Güncellenmiş test iş akışını detaylandıran bir olay sonrası inceleme (post-mortem) yayınlamayı ve diğer yayıncıların aynı hataya düşmemesi için revize edilmiş betiği kamuoyuyla paylaşmayı planlıyorlar. Bu olay bir hatırlatıcı niteliğinde: Çok küçük bir ayrıştırma hatası bile yazarın haftalar süren emeğini silebilir, bu da titiz test yapmayı tartışmaya kapalı bir zorunluluk haline getirir.