Supabase'in Sessiz Varsayılanları Dört Prodüksiyon Kazasına Yol Açtı
Bir haftada yaşanan dört Supabase olayı tek bir kök nedene bağlanıyor: veritabanı sessizce yanlış veri döndürüyor, hata fırlatmıyor. Üç somut önlem öneriliyor.
Bir hafta içinde art arda gelen dört Supabase olayı incelendiğinde ortaya tek bir kalıp çıkıyor: veritabanı hiçbir istisna fırlatmadan, HTTP 200 dönerek yanlış veya eksik veri üretiyor. İlk vakada bir SQL fonksiyonuna açıkça REVOKE verilmediği için varsayılan olarak anonim erişime açık kalıyor; ikincisinde ON DELETE SET NULL ile CHECK NOT NULL kısıtları çelişerek yanıltıcı bir hata mesajı üretiyor; üçüncüsünde RLS politikalarının birbirini çağırması sonsuz döngüye yol açıyor; dördüncüsünde ise sıralama belirtilmeyen bir sorgu, PostgREST'in bin satırlık varsayılan limitine takılıp veriyi ctid'e göre sessizce kırpıyor. Dört durumda da birim testleri geçiyor, kod incelemesi sorunu yakalayamıyor, çünkü hata mantıkta değil; hacimde, yetki bağlamında ve tabloya özgü geçmişte gizli.
Yazar bu tekrarı bir tesadüf değil, yapısal bir sorun olarak okuyor: platformun belgelenmemiş varsayılan davranışları, geliştiricinin koduna görünmeden işlenen 'donmuş' bir sözleşme gibi davranıyor. Bu nedenle üç somut kural öneriliyor: her belgesiz varsayılan davranış ya bir ADR/kural dosyasında açıkça yazılmalı ya da bir guard (ESLint kuralı, SQL CHECK, pre-commit hook) ile engellenmeli; tekrar eden desenler için insan kod incelemesi yerine AST tabanlı statik analiz kuralları devreye alınmalı; ve gerçek davranışı yakalamak için günlük prod izleme probları kurulmalı, çünkü bu tür kusurlar test ortamında hiçbir zaman tetiklenmiyor. Ayrıca yazar, vendor varsayılanlarının bir yapay zeka ajanından değil doğrudan resmi dokümantasyondan doğrulanması gerektiğini vurguluyor.
Sonuç olarak metin, Supabase/PostgREST kullanan mühendisler için somut bir uyarı niteliği taşıyor: platform varsayılanları kod incelemesinde görünmez, testlerde tetiklenmez, ama üretimde ciddi veri bütünlüğü ve güvenlik sorunlarına yol açabilir.