Bir mağaza başarısız görünen bütün sipariş e-postalarını seçip topluca yeniden gönderiyor. Geçici ertelemeler, kalıcı retler, engellenmiş alıcılar ve sonucu belirsiz istekler aynı kuyruğa dönüyor. Bazı müşteriler yinelenen iletiler alırken geçersiz adreslere tekrar gönderim yapılıyor.
Güvenli yeniden deneme, her hata için otomatik verilen bir karar değildir. Önceki denemenin sonucu, bildirimin hâlâ geçerli olup olmadığı ve sağlayıcının iletiyi daha önce kabul edip etmediği ayrı ayrı incelenmelidir.
Bu konu ne anlama gelir?
Yeniden deneme, aynı bildirimi teslim etmek için yapılan yeni gönderim girişimidir. Yalnız önceki sonuç biliniyor ve ileti hâlâ geçerliyse uygundur. SMTP 4xx yanıtları çoğunlukla geçici durumu gösterir; 5xx yanıtları ise neden düzeltilmediği sürece mevcut istek için kalıcıdır.
Zaman aşımının hangi noktada oluştuğu önemlidir. Bağlantı ileti aktarılmadan kesildiyse yeni deneme güvenli olabilir. Yanıt, ileti verisinin sonu gönderildikten sonra kaybolduysa sağlayıcı e-postayı kabul etmiş olabilir. Kayıtlar eşleştirilmeden yeniden göndermek yinelenen ileti üretir.
Gerçekçi bir WordPress örneği
Hata kuyruğunda 421 ertelemesi, 550 politika reddi, hard bounce sonrasında engellenmiş bir adres ve SMTP yanıtı kaybolmuş bir sipariş e-postası bulunuyor. Toplu gönderim aracı dört kaydı da aynı biçimde işliyor.
Yönetici 421 kaydını sınırlı gecikmeyle yeniden deniyor, 550 reddiyle engellenmiş adresi durduruyor. Belirsiz sipariş e-postası için sağlayıcı kayıtlarında kabul kimliği bulunuyor; böylece müşteriye ikinci kez bildirim gönderilmiyor.
Neden önemlidir ve ne zaman kullanılır?
Kontrolsüz yeniden denemeler müşteriyi rahatsız edebilir, gönderen itibarına zarar verebilir, hız sınırlarını tetikleyebilir ve bir kez çalışması gereken süreçleri yineleyebilir. Parola sıfırlama bağlantısı gibi süreli içerikler yeni denemeye kadar geçerliliğini yitirebilir.
Karar; hata sınıfına, alıcının durumuna, iletinin yaşına ve bildirimin amacına bağlıdır. Kimlik doğrulama ve politika hataları düzeltilmelidir. Hard bounce alan ve engelleme listesine giren adresler durur; geçici ertelemeler uygun bekleme sonrasında yeniden denenebilir.
Yalnız hâlâ geçerli ve hatası açıkça geçici olan olayları tekrar deneyin. Sonuç belirsizse önce sağlayıcının iletiyi kabul etmediğini doğrulayın.
Yeni başlayanlar için anlaşılır yol
- Toplu yeniden gönderimi durdurun; olay kimliğini, alıcıyı, deneme zamanlarını, yanıt aşamasını ve kodunu, sağlayıcı kimliğini, içerik sürümünü ve son geçerlilik zamanını koruyun.
- Her kaydı geçici, kalıcı, engellenmiş, süresi dolmuş, kimlik veya politika hatası ya da belirsiz sonuç olarak sınıflandırın.
- Belirsiz sonucu yeni gönderimden önce sağlayıcı kayıtlarıyla eşleştirin. Yerel zaman aşımı, iletinin kabul edilmediğini tek başına göstermez.
- Yalnız onaylanan geçici sınıfı, sınırlandırılmış üstel bekleme ve jitter ile yeniden deneyin. Deneme sayısına ve toplam yaşa üst sınır koyun.
- Bütün denemelerde sipariş veya bildirim olayını temsil eden aynı anahtarı kullanın. Düzelen iletinin yalnız bir kez teslim edildiğini ve durdurulan sınıfların yeniden kuyruğa girmediğini doğrulayın.
İleri teknik yol
Idempotency, sipariş veya bildirim olayı düzeyinde tasarlanmalıdır. Sipariş veya bildirim kimliğini SMTP deneme kimliklerinden ayrı tutun; her yeniden denemenin yeni sipariş ya da bildirim işlemi üretmesini önleyin. Birbirine bağlı iletilerde sıra korunmalıdır.
Birden fazla alıcının kısmen kabul edilmesini alıcı bazında değerlendirin. Bağlantı zaman aşımıyla SMTP DATAsonrasındaki zaman aşımını ayırın ve gecikmeli sağlayıcı olayları için belirlenmiş bir uzlaştırma süresi tanıyın. Deneme hakkı tükenen veya çözülemeyen kayıtları dead-letter kuyruğuna ya da manuel incelemeye alın.
Parola sıfırlama veya doğrulama bağlantısı gibi içeriklerin süresi dolduysa eski iletiyi tekrar göndermeyin. Yeni bir güvenlik olayı gerekip gerekmediğine ilgili ürün sorumlusu karar vermelidir.
Riskler, sık hatalar, yedekleme ve geri alma
Anında döngüler, sınırsız denemeler, hard bounce sonrasında gönderim, engelleme listesini yok saymak ve içeriği incelemeden değiştirmek zararı büyütür. Yinelenen teslim görülürse, hız sınırı yanıtları artarsa, sınıflandırma yoksa veya sağlayıcı kaydı yerel durumla çelişirse worker’ı durdurun.
Yeniden deneme davranışını değiştirmeden önce kuyruk kurallarını, engelleme verilerini ve önceki worker ayarını yedekleyin. Kalıcı kayıtlar yeniden etkinleşirse, sıra bozulursa, aynı sipariş veya bildirim olayı iki kez işlenirse veya güvenli hız sınırlaması geri getirilemezse önceki yapılandırmaya dönün. İlk hata kaydını silmeyin.
AIOWS nasıl yardımcı olur?
AIOWS SMTP Yöneticisi
AIOWS SMTP Yöneticisi, yönetici yeniden gönderim kararı verirken WordPress tarafındaki SMTP yolunu, kontrollü test sonuçlarını ve ilgili hata bağlamını görünür tutabilir. Kayıtlı yanıt, gönderim hatasıyla hiç oluşturulmamış uygulama olayını ayırmaya yardımcı olur.
Modüldeki bilgiyi sağlayıcı kaydıyla birlikte değerlendirin. Sağlayıcı sonucu bulunmayan yerel zaman aşımı belirsizdir; kalıcı ret veya engellenmiş alıcı aynı değişmemiş yoldan zorla yeniden gönderilmemelidir. Düzeltilen posta yolunu gerçek WordPress bildirimlerinde kullanmadan önce hassas veri içermeyen bir test iletisiyle sınayın.
AIOWS sipariş e-postasının veya sıfırlama bağlantısının hâlâ geçerli olup olmadığına karar vermez, idempotency sağlamaz, sağlayıcı engelini aşmaz ve uygulama kodunun oluşturduğu yinelenen iletileri önleyemez. Yeniden deneme politikası, kuyruk yönetimi ve sipariş kayıtlarıyla bildirim kayıtlarının eşleştirilmesi SMTP ayarının dışındaki operasyonel sorumluluklardır.
AIOWS SMTP Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress E-posta Göndermiyor: Nedenleri ve Çözümleri
- WordPress E-posta Loglarıyla Teslimat Sorunlarını Tanılama
- WordPress SMTP Gönderim Limiti Aşıldı: Nedenler ve Çözümler
Sonuç ve önerilen yol
Önce hatayı sınıflandırın, sonra yeniden gönderin. Yalnız geçerli ve geçici işleri sıkı sınırlarla deneyin, belirsiz sonuçları sağlayıcı kayıtlarıyla netleştirin; kalıcı, engellenmiş ve süresi dolmuş kayıtları etkin kuyruğa döndürmeyin.
