Hold stale tender notification retries for review
This commit is contained in:
@@ -860,3 +860,10 @@ Taslak türü seçicisine erişilebilir ad eklendi. Üretim derlemesi geçti. Ö
|
||||
- E-posta kriter açıklaması ortak escapeHtml ile kaçırılır; kullanıcı kriterindeki HTML bağlantısı/etiketi e-posta gövdesine işaretleme olarak giremez. Konu satırı düz metnini korur.
|
||||
- 195 otomatik test geçti. Yalnız sunucu ve test kodu değiştiğinden frontend derlemesi tekrarlanmadı. Testler dış e-posta göndermez.
|
||||
- Bu kontrol beslemenin yapısını doğrular; şekli geçerli fakat eksik/eski kaynakların tamlık ve güncelliğini kanıtlamaz. Bekleyen gönderimin ihalesi sonradan iptal olduğunda yeniden değerlendirme, gerçek sağlayıcı teslimi ve diğer plan kabulleri açık.
|
||||
|
||||
### Bekleyen e-postada ihale güncellik kontrolü — 6 Eylül 2026
|
||||
- Kuyruktan alınan sabit e-posta, sağlayıcı çağrısı öncesinde o turun doğrulanmış kaynak listesiyle karşılaştırılır. İlan kayıp, iptal/sonuçlanmış, süresi geçmiş, zamanı belirsiz veya son teklif zamanı değişmişse eski içerik yeniden gönderilmez. Sabit digest eksik/kimlikleri uyumsuzsa da durur.
|
||||
- holdDelivery mevcut lease sahibinin sending kaydını uncertain inceleme durumuna alır; payload/UUID/görülmüş kayıtlar değişmez. Eski worker hold/başarı/hata ile kaydı değiştiremez. Sonraki reserve turu inceleme gerekçesini artık genel bir hatayla ezmez.
|
||||
- İnceleme mevcut yönetici outbox akışını kullanır: sağlayıcı kaydıyla gönderildiğini doğrulama veya yeniden göndermeden kapatma. Tarihi değişen grubun içeriği aynı idempotency key altında yeniden yazılmaz.
|
||||
- 197 otomatik test geçti. Eksik ilan, iptal, süre aşımı, eksik saat, ileri alınmış tarih; provider/ack çağrısının yapılmaması; hold lease sınırı; sonraki turda gerekçenin korunması doğrulandı. Önceki gerçek süreç kesintisi ve aynı anahtarla tekrar testleri de geçti. Dış sağlayıcıya gönderim yapılmadı.
|
||||
- Kontrol o turda alınan kaynak görünümüne dayanır; canlı kaynağın sonradan değişmesini veya geçerli şekle sahip eski beslemeyi tespit garantisi vermez. Başlık değişikliği tek başına tekrar anahtarını bozmaz. UI değişmediğinden frontend derlemesi tekrarlanmadı.
|
||||
|
||||
@@ -69,3 +69,6 @@ notify.sqlite abonelik kimliği geçişi: `criteria_key` sütunu eklendi; konu v
|
||||
Kalıcı e-posta kuyruğu aynı notify.sqlite içinde `notification_outbox` tablosundadır. Tam içerik/gönderen/alıcı ve ihale listesi ile sağlayıcı istek kimliği burada korunur; yedeğe dahil edilmelidir. Bir bekleyen grup abonelik başına tek aktif kayıtla tutulur. 120 saniyelik işçi sahipliği, 30 saniyelik sağlayıcı isteğinden uzundur. İlk denemeden 23 saat sonra belirsiz kayıt otomatik tekrar gönderilmez; Resend'in 24 saatlik tekrar önleme süresine güvenli pay bırakılır. Yönetici sağlayıcı kaydını doğrulamalıdır; Mobil PWA sayfasındaki yöneticiye özel E-posta gönderim incelemesi bölümünden kayıt karara bağlanır. Sağlayıcı kabulü doğrulandıysa gönderim kimliği/onay/açıklama ile kapatılır; aksi halde yeniden göndermeden kapatma seçilebilir. Her iki işlem de yeni e-posta göndermez ve açıklamalı karar geçmişini korur. Bekleyen iş varken sağlayıcı hesabı/anahtarı değiştirilmemelidir: tekrar önleme anahtarı farklı sağlayıcı hesapları arasında garanti vermez. Eski uygulamaya dönmek kuyruğu yok sayabileceğinden kod ve DB geri dönüşü birlikte değerlendirilmelidir.
|
||||
|
||||
`node --test tests/outbox-crash.test.mjs`, sağlayıcı kabulünden sonra commit öncesi/sonrası gerçek SIGKILL kurtarmasını izole volume'da sınar. Ayrı süreçte aynı payload/istek kimliği ve SQLite bütünlüğü doğrulanır. Sağlayıcı yerel bir simülatördür; test gerçek Resend hesabının idempotency davranışını veya üretim platformundaki disk kurtarmasını kanıtlamaz.
|
||||
|
||||
### Güncellik nedeniyle tutulan e-postalar
|
||||
Kuyruktaki ilanın artık kaynakta bulunmaması, teklif zamanının değişmesi, iptal/sonuç veya süre aşımı halinde otomatik tekrar durur ve yönetici inceleme listesinde gerekçe görünür. Liste sınırlaması veya geçici kaynak eksikliği de bu durumu oluşturabilir. Önce sağlayıcı kaydını ve resmi ilanı karşılaştırın; mevcut karar akışından gönderildiğini kanıtlayarak veya yeniden göndermeden kapatarak çözün. Payload ya da idempotency anahtarını elle değiştirmeyin. Yeniden göndermeden kapatmak bu gruptaki ihale kimliklerini görülmüş sayar; değişen ilan için otomatik yeni e-posta taahhüt edilmez.
|
||||
|
||||
Reference in New Issue
Block a user