AI iş akışında zaman aşımı: aynı işi ikinci kez başlatmayı önleyin.

Yanıt gelmediğinde neyin gerçekleştiğini biliyor musunuz?

Bir ajan belge inceleme işi açmak için araca istek gönderiyor. Sunucu işi kaydediyor, fakat yanıt bağlantıda kayboluyor. Ajan ‘İşlem başarısız’ diyerek yeniden iş açarsa iki kayıt oluşabilir. Kullanıcı tek bir inceleme istemiştir. Buradaki hata, yanıt alınamamasını işlemin hiç gerçekleşmediğiyle eşitlemektir. İki olay farklı sistemlerde ve farklı zamanlarda yaşanır.

Tekrar denemenin güvenli olması için aynı mantıksal isteğin yeniden gelmesiyle yeni bir iş isteğinin ayırt edilmesi gerekir. AWS Builders’ Library, istemcinin ürettiği istek kimliğini bu niyeti belirtmek için kullanır. Aynı kimlikle tekrar gelen isteğin ek yan etki oluşturmaması idempotent davranıştır. Bu özellik aracın sözleşmesinde ve uygulamasında bulunmalıdır; modelin ‘iki kez yapma’ talimatını hatırlamasına bırakılamaz.Kaynak: AWS Builders’ Library — Making retries safe with idempotent APIs

Bu yazının uygulaması, gerçek belge veya sisteme bağlanmayan sentetik bir inceleme kaydıdır. Ödeme, e-posta veya üretim işlemi başlatılmıyor. Bir sunucu uygulamasının hazır kodunu sunmak yerine, iş sahibiyle teknik ekibin birlikte doğrulayabileceği durumları hazırlıyoruz. Aynı yaklaşımı farklı araçlara taşımadan önce her aracın tekrar sözleşmesini ayrı incelemek gerekir.

Kimliği denemeye değil, yapılacak işe bağlayın

İş: R-17 belgesinin V3 sürümü için iç inceleme kaydı aç.
Mantıksal istek kimliği: K-701.
Kapsam: Aynı kullanıcı ve bu inceleme oluşturma işlemi.
İçerik: belge=R-17, sürüm=V3, ekip=teknik.
Beklenen tek sonuç: İNCELEME-81 kaydı.
Tekrar: K-701 ve aynı içerikle aynı sonuç döner; yeni kayıt oluşturulmaz.
Değişiklik: Aynı K-701 ile V4 gelirse içerik çatışması olarak durur.

K-701 bir HTTP denemesinin numarası değildir. Ağ bağlantısı yeniden kurulduğunda veya kullanıcı aynı bekleyen işlemi tekrar denediğinde korunur. Yeni kimlik üretmek, sunucuya yeni bir iş niyeti bildirebilir. Buna karşılık kullanıcı açıkça V4 için ayrıca inceleme isterse bu yeni bir mantıksal işlemdir. Önceki sonucu belirsiz bırakıp yalnızca kimliği değiştirerek yeniden denemek, bu ayrımı bozar.

Belge ve ekip alanlarının aynı olması da her zaman aynı niyeti göstermez. Aynı belge için daha sonra ikinci bağımsız inceleme istenebilir. Bu nedenle yalnızca içerik benzerliğiyle tüm kayıtları tekleştirmek doğru değildir. Kullanıcı niyeti, yetkili kapsam ve sunucunun işlem kuralları birlikte tanımlanmalıdır. Kimlik aynı olsa bile başka kullanıcının sonucunun dönmemesi için kapsam kontrolü gerekir.

Başarılı yolun arasına belirsizlik yerleştirin

İlk altı olayın sonunda iki inceleme kaydı bulunur; altı ağ hareketi altı iş değildir. Bu beklenen sonuç, bir araçta çalıştırılmış deney kaydı olarak sunulmuyor. Teknik uygulama yapılırsa hem dönen yanıt hem kalıcı kayıt sayısı test edilmelidir. Ekranda tek başarı mesajı görülmesi, arka planda ikinci kaydın oluşmadığını kanıtlamaz.

Eşzamanlı iki isteğin ikisi de önce ‘kayıt yok’ sonucunu görüp sonra yazabilir. Bu nedenle kontrol ve oluşturma arasındaki yarış durumunu uygulama düzeyinde çözmek gerekir. AWS’nin açıklaması, kimlik kaydı ile ilgili mutasyonun atomik olarak ele alınmasını vurgular. Uygulamanın veri tabanı ve dış araçları bu sınırı nasıl sağlıyor, teknik ekip açıkça göstermelidir.Kaynak: AWS Builders’ Library — Making retries safe with idempotent APIs

İşleniyor, tamamlandı ve bilinmiyor farklı durumlardır

Bağlam: Sentetik belge inceleme akışının hata yollarını tasarlıyorum.
Girdi: [işlem sözleşmesi] ve [olay tablosu].
Görev: Her olayda istemcinin bildiğini, sunucuda gerçekleşmiş olabilecek etkiyi ve izinli sonraki adımı ayır.
Kısıtlar: Zaman aşımını işlemin yapılmadığına kanıt sayma. Aracın desteklemediği durum sorgusu veya tekilleştirme özelliği uydurma. Belirsiz dış işlemi yeni kimlikle tekrar başlatma.
Çıktı: Olay | bilinen durum | sonraki adım | eksik teknik sözleşme.
Kontrol: Aynı niyetin tekrarıyla açıkça yeni bir talep birbirinden ayrılmalı.

Aracın idempotency desteği yoksa bu tablodaki ‘aynı sonucu döndür’ davranışı kendiliğinden oluşmaz. Durum sorgusu, uzlaştırma veya insan incelemesi gerekebilir. Bir işlemin geri alınabilir olması da ikinci kopyayı önemsiz yapmaz; geri alma başarısız olabilir veya başka süreçleri tetiklemiş olabilir. Sistem sınırlarını bilmediğiniz bir durumda modelden emin görünen bir karar istemeyin.

Kimlik saklama süresi de sözleşmenin parçasıdır

Kimlik kayıtları sonsuza kadar tutulmayabilir. Eski tekrarlar kabul ediliyorsa hangi süre içinde aynı davranışın garanti edildiği belirtilmelidir. Süre dolduktan sonra gelen isteği yeni saymanın iş açısından uygun olup olmadığını ayrıca değerlendirin. Tamamlanmış bir kaydın sonradan silinmesi de eski isteği otomatik olarak yeniden oluşturma izni vermez. Başlangıçtaki niyetin sonucuyla yeni bir oluşturma kararı farklıdır.

• İlk kayıt yazıldıktan sonra yanıtı kaybettirerek sonucu kontrol edin.
• Aynı isteği eşzamanlı gönderip kalıcı etki sayısını ölçün.
• Aynı kimlikle farklı içerik ve farklı kullanıcı kapsamını sınayın.
• Kimlik saklama sınırını ve geç gelen isteği ayrı test edin.
• Arka plandaki ikinci sistem etkisini ayrıca inceleyin; ilk veri tabanının atomik olması her bağlantıyı kapsamaz.

Küçük alıştırma: Ajan, ikinci olayda K-701 yerine K-999 üretsin. Sunucu yeni kimlikleri yeni niyet sayıyorsa ikinci inceleme oluşabilir. ‘Aynı belgeydi’ açıklaması bunu engellemez. Beklenen düzeltme, yeniden denemede ilk mantıksal kimliği korumak ve ilk işlemin durumunu sözleşmeye göre ele almaktır; oluştuktan sonra iki kaydı metin benzerliğiyle silmek değildir.

Kendi akışınızda tek bir dış etki seçip bu olayları kağıt üzerinde yürütün. Sonra uygulama testinde beklenen kayıt sayısını ve gerçek araç etkisini karşılaştırın. Böylece başarılı bir demo dışında, yanıtın kaybolduğu anda sistemin hangi kararı vereceğini de önceden tanımlamış olursunuz.