Idempotentlik

Ishlaydi

Tarmoq ishonchsiz. So’rov ketadi, javob yo’qoladi, kod qayta urinadi — va mijoz ikkita SMS oladi. Idempotentlik aynan shuni to’sadi.

Ikki qatlam

Himoya ikki joyda ishlaydi va ular boshqa-boshqa:

Qatlam	Nima qiladi	Nima bilan
Transport	Ayni so’rovni takrorlamaydi	`idempotency_key`
Semantik	Ayni niyatni takrorlamaydi	Operation Ledger

tenant_id → business_id → actor_ref → capability_id
          → resource_ref → business_window

⚡ capability_id, tool nomi emas. Shuning uchun konnektor almashsa (Bitrix24 → 1C) idempotentlik buzilmaydi: niyat o’sha-o’sha.

Bazada bu UNIQUE (tenant_id, semantic_key) — yagona haqiqiy himoya.

# Biznes hodisasiga bog'langan — barqaror
idempotency_key = f"buyurtma-{order_id}-tasdiq"

Ayni buyurtma uchun qayta chaqirsangiz — ikkinchi effekt yo’q.

idempotency_key = str(uuid4())          # har safar yangi → himoya YO'Q
idempotency_key = str(time.time())      # ayni sabab

Tasodifiy kalit — himoyani o’chirish bilan barobar.

Kunlik hisobot kabi amal har kuni takrorlanishi kerak:

idempotency_key = f"kunlik-hisobot-{date.today()}"

Bu business_window tushunchasi: sana kalitning bir qismi bo’ladi, shuning uchun ertaga ayni amal bloklanmaydi.

Holat	HTTP	Ma’nosi
Ayni kalit + ayni tana	`200`	Mavjud ijro qaytadi
Ayni kalit + boshqa tana	`409`	Jim ustiga yozish yo’q

⚠ 409 — bu xato emas, himoya. U «siz ayni kalitni boshqa niyat uchun ishlatyapsiz» degani.

Amal allaqachon boshlangan bo’lsa konnektorga borilmaydi:

Mavjud holat	Javob
`VERIFIED`	`409 duplicate_intent_verified` — allaqachon bajarilgan
Boshqasi	`409 duplicate_intent` — boshlangan, holati noaniq

Farq ataylab: birinchisi muvaffaqiyat (yangi effekt kerak emas), ikkinchisi esa «kuting».