100 eski yaz urununu sildim ama R2 storage faturam degismedi — product DELETE image cleanup (PR #603 BBB F5)

Antalya Kaleici 38-yas Antalya Sis Kebap + Tarcinli Kunefe 14-yil 50-cover Akdeniz tatlisi + Antalya sis kebap sahibi Burhan thMenu Pro 23 ay. Antalya yaz-kis musteri profili cok farkli yazin Avrupali turist + sokak yemek + soguk icecek kisin yerel + sicak corba + doner. Burhan her sezon menu refresh Mayis yaz menu 60+ urun Ekim yaz menu silinir 60+ urun delete + kis menu acilir 5 yil pattern. Bu yil Ekim 62 yaz urun silindikten sonra R2 storage widget bakti 8.4GB/10GB Pro quota. Gecen ay ayni. Onceki ay 8.3GB. Yilin basi 6.1GB. Storage hic dusmuyor sadece artiyor. Yilda iki sezon × 60 urun = 120 urun delete × 2 resim ortalama = 240 resim/yil delete × 5 yil = 1200 resim silindi sanildi ama R2 da. 350KB ortalama → ~420 MB ghost storage quota %4. Support yazdi Pro tier R2 quota 10GB yilda 240 resim silmem gerekiyor storage hic dusmuyor bug mi. 3 yanlis teori (1) soft-delete kalintisi products deleted_at timestamp + product_images orphan SELECT COUNT 2847 orphan + 1247 deleted products; (2) R2 lifecycle expire R2 standart yok otomatik expire yok R2 list menu-images/<burhan_id>/* 4521 R2 object aktif row 1674 → 2847 orphan; (3) DELETE handler R2 dokunulmuyor dogru. Adli analiz apps/web-admin/src/app/api/products/[id]/route.ts DELETE UPDATE products SET deleted_at=? sadece soft + R2 dokunulmuyor + product_images orphan. apps/web-admin/src/app/api/menus/[id]/route.ts DELETE menu hard-delete FK-cascade products + product_images ama R2 dokunulmuyor. Iki path R2 binary objects orphan. URL bilen silinmis urun resmi hala acabiliyor GDPR Art.17 right-to-be-forgotten yetersiz. PR #603 batch BBB F5 3-katmanli fix Layer 1 product DELETE image URL SELECT + canonical R2 key regex r2KeyRegex=/^https?:\/\/[^/]+\/(menu-images\/[a-f0-9-]{36}\/[A-Za-z0-9._-]+)$/ siki path traversal + cross-tenant prefix bypass + arbitrary URL reject. Layer 2 cross-tenant prefix guard extracted key restaurant_id segment session restaurant_id ile eslesmeli filter k.includes menu-images/${userRestaurantId}/ izolasyon. Layer 3 best-effort MENU_IMAGES.delete(key) per key R2 delete API hata silent fail audit log r2_objects_deleted: 12 / r2_objects_attempted: 14. Database cleanup product icin DELETE FROM product_images WHERE product_id=? menu FK-cascade. Production audit son N-gun tum restoran orphan R2 object 184712 ~71GB. Pro tier toplam quota 10GB × 247 Pro+ aboneligi = 2470GB orphan ~%3. Backfill cron r2-orphan-cleanup bir defalik manuel paginated per-restaurant R2 list + product_images row check + orphan delete 6 saat. Burhan account 2847 orphan delete 8.4GB → 4.2GB email PR #603 BBB F5 shipped retro-backfill complete %50 dustu 1-ay Pro credit Twitter 5 yillik ghost storage 870 engagement. Audit log r2_objects_deleted operator dashboard Gecen ay R2 dan kac object kaldirdiniz widget. Fabrizio Napoli Spaccanapoli Via dei Tribunali 42-yas Pizzeria di Borgo San Lorenzo 18-yil 50-cover Neapolitan ayni pattern 4 yil yaz/kis menu refresh storage 7.1GB → 3.4GB paralel ticket. Pattern DELETE sadece DB row degil iliskili binary asset + audit log uclusu canonical soft-delete+R2 dokunulmuyor silent billing waste + silent GDPR Art.17 ihlal hard-delete cascade product_images + R2 hala dokunulmuyor ayni sorun. Sibling sweep customer profile photo (PR #611 DDD F1 erase-user) + brand logo (PR #661 XI F3) + menu cover image + restaurant logo (PR #603 BBB F5) + backup snapshots ayri cron. Implementation DELETE handler binary asset URL SELECT + canonical R2 key siki regex extract + cross-tenant prefix guard + best-effort R2.delete try/catch + count attempted/deleted + DB cleanup + audit log + operator dashboard widget + quarterly orphan sweep cron + GDPR Art.17 erase-user yolu ile uyumlu. PR #603 referans.

İlgili makaleler