Ekrandaki zaman aşımı sunucunun işlemi tamamlamadığı anlamına gelmeyebilir. Sonuç belirsizken ikinci iade oluşturmak çift hareket riski doğurur.

Kap fiziksel olarak depodaysa bunu mevcut usulle kaydedin ve dijital belirsizliği ayrı işaretleyin. Tekrar tarama ilk inceleme adımı olmasın.

Sonuç için hangi kayda bakılır?

Bulunan durumSonraki inceleme
Hedef hareket oluşmuşÖzgün istek ve fiziksel işlemle eşleştir
İstek reddedilmişRet nedenini çözmeden tekrar gönderme
İşlem hala sürüyorBelgelenmiş durum sorgusuyla takip et
Sonuç bulunamıyorBelirsiz kaydı ayrı tut ve yetkili kurtarma yolunu kullan

Hedefte aynı kap için bir satır görmek de yeterli değildir. Önceki günün iadesi veya başka bir görev olabilir. Kaynak istek, kap, olay türü ve görev bağı birlikte eşleşsin. Yalnız son görülen işlemin saatini temel almak, gecikmiş kayıtların bulunduğu sistemlerde yanlış güven verir.

IETF HTTP standardı, aynı isteğin tekrarının aynı amaçlanan etkiyi üretmesini ayrı bir özellik olarak tanımlar. Bir işlemin bu özelliğe sahip olduğu bilinmeden kör otomatik tekrar yapılmamasını belirtir. Uygulamanızın ekrandaki tekrar düğmesi için davranışı sistem sorumlusundan öğrenin. Düğmenin varlığı tekilleştirme güvencesi değildir.

Yeniden gönderim gerekiyorsa aynı işin kaynak kimliğinin korunup korunmadığı açıklansın. Her denemede yeni numara üreten bir akış, hedefte aynı fiziksel işi yeni işlem gibi gösterebilir. Öte yandan yeni bir gerçek iade için eski anahtarın kullanılması da o hareketi kaybettirebilir. İstek kimliği ile kap kimliği bu nedenle ayrıdır.

Kurtarma yolunu önceden deneyin

Test ortamında hareketin yazıldığı fakat cevabın kullanıcıya ulaşmadığı durumu kurun. Ekran yeniden açıldığında kullanıcı sonucu bulabiliyor mu bakın. Teknik ekip hem kabul edilmiş hem hiç uygulanmamış istek için farklı kurtarma davranışını gösterebilsin. Canlı stok üzerinde tekrar tekrar deneme yapılmasın.

Kapanışta kap stoğu, müşteri listesi ve sonraki tahsisler aynı nihai hareketle uzlaşsın. Fazla kayıt varsa düzeltme izi korunsun.