Status 

Stöd för idempotensnyckel är partiellt idag. Utvalda interna retry-mutationer — till exempel order-billing retry och refund-billing retry — accepterar redan en idempotensnyckel och använder den för att deduplicera anrop till betalningsprocessorn nedströms. Det finns ännu inte ett standardiserat idempotencyKey-argument på alla kundvända create-mutationer i Zonos Graph; det finns på roadmapen. Tills det lanseras, använd mönstren nedan för att hålla mutationer säkra att försöka igen.

Mutationer som är säkra som standard 

Vissa mutationer är naturligt idempotenta eftersom de upsertar utifrån en stabil identifierare som ni tillhandahåller. När ni anropar dessa med samma indata blir resultatet detsamma — det finns ingen risk att skapa dubbletter.

• Mutationer som tar en unik handlartillhandahållen identifierare (till exempel en orders externalId) returnerar den befintliga posten vid ett upprepat anrop i stället för att skapa en ny.
• Skrivskyddade operationer (queries) är alltid säkra att försöka igen.

När ni kan knyta er egen stabila identifierare till resursen ni skapar, föredra den vägen.

Mönster för mutationer som inte är naturligt idempotenta 

För mutationer som skapar resurser utan en handlartillhandahållen nyckel, behandla dem som högst en gång från er sida:

1. Spara begäran innan ni skickar. Skriv en rad i er egen databas (status pending) före nätverksanropet.
2. Skicka mutationen. Vid lyckat resultat, spara det returnerade resurs-id:t mot er pending-rad (status committed).
3. Vid nätverksfel, försök inte blint igen. Fråga Zonos Graph för att avgöra om resursen skapades (till exempel genom att lista resurser som skapats under de senaste minuterna för ert konto, eller genom att fråga efter en relaterad resurs ni kan korrelera). Försök bara igen om ni kan bekräfta att resursen inte finns.
4. Använd en unik constraint i er egen databas på den affärsnyckel som representerar begäran, så att en dubblettretry från er egen applikation inte kan skicka dubbelt.

Webhook-leverans är minst en gång 

När ni konsumerar Zonos-webhooks, utforma handlers så att de är idempotenta — samma händelse kan levereras mer än en gång. Deduplicera utifrån händelse-id. Se Webhooks för fältet för händelse-id.

Vart plattformen är på väg 

Den underliggande plattformen kör redan flöden med idempotensnyckel i produktion för billing-retries: nyckeln avgränsar ett retry-försök och förhindrar dubbla anrop till betalningsprocessorn. Vi arbetar med att exponera samma mönster som ett valfritt idempotencyKey-argument på kundvända create-mutationer. När det anges returnerar Graph det ursprungliga svaret för varje efterföljande anrop med samma nyckel inom ett lagringsfönster. Den här sidan uppdateras när ytan blir allmänt tillgänglig.

Om standardiserade idempotensnycklar på kundvända mutationer blockerar er integration, kontakta support.