Supabase'in sessiz varsayılanları: bir haftada dört olay, tek kök neden

Bir hafta içinde birbirinden bağımsız görünen dört Supabase olayı: fonksiyonlarda varsayılan anon EXECUTE yetkisi, ON DELETE SET NULL ile CHECK NOT NULL çakışması, auth.users ile user_roles arasında RLS recursion ve .select() zincirinde .order() eksikliğinin yol açtığı sessiz 1000 satır sınırı. Dördünde de Postgres hiçbir exception fırlatmıyor, HTTP 200 dönüyor, payload sessizce eksik veya yanlış geliyor. Unit testler küçük seed veriyle geçiyor, code review tek satırlık zinciri onaylıyor; asıl kırılma yalnızca prod hacminde, gerçek auth bağlamında ve policy zincirlerinde ortaya çıkıyor.

Yazar bu dört vakayı tek bir aile olarak okuyor: platformun belgelenmemiş varsayılan davranışları, geliştiricinin repo'sunda hiç görünmeyen ama prod'u ayakta tutan örtük sözleşmelere dönüşüyor. Buna karşı üç somut kural öneriliyor: belirtilmemiş her vendor default'u ya bir ADR/kural dosyasında metinsel olarak belgelenip assert edilmeli, ya da ESLint kuralı veya SQL CHECK gibi maddi bir engelle kapatılmalı; onlarca kez tekrarlanan pattern'lerde AST tabanlı lint kuralları insan code review'undan daha güvenilir (yazar ctid vakasında 178 ham uyarıyı 108 gerçek hedefe indiren beş gürültü-azaltma mekanizması kullanmış); ve bu tür varsayılanlar test ortamında görünmediği için günlük prod drift sondaları ile sayaçların şüpheli tavanlara yaklaşıp yaklaşmadığı izlenmeli.

Backend ve platform mühendisleri için çıkarım net: vendor varsayılanlarını okunmamış dokümantasyon maddeleri değil, kod tabanına sessizce sızan tasarım kararları olarak ele almak, benzer olay zincirlerini daha ortaya çıkmadan kesebilir.