Status 

Støtte for idempotensnøkkel er delvis i dag. Enkelte interne gjentakelsesmutasjoner — for eksempel gjentakelsesflytene for ordrefakturering og refusjonsfakturering — godtar allerede en idempotensnøkkel og bruker den til å deduplisere nedstrøms kall til betalingsbehandleren. Det finnes ennå ikke noe standardisert idempotencyKey-argument på tvers av alle kundevendte opprettelsesmutasjoner på Zonos Graph; det er på veikartet. Inntil det er på plass, bruk mønstrene nedenfor for å holde mutasjoner trygge å prøve på nytt.

Mutasjoner som er sikre som standard 

Noen mutasjoner er naturlig idempotente fordi de setter inn eller oppdaterer basert på en stabil identifikator du oppgir. Når du kaller disse med samme inndata, blir resultatet det samme — det er ingen risiko for å opprette duplikater.

• Mutasjoner som tar imot en unik, forhandlerlevert identifikator (for eksempel externalId for en ordre) returnerer den eksisterende posten ved et gjentatt kall i stedet for å opprette en ny.
• Skrivebeskyttede operasjoner (spørringer) er alltid trygge å prøve på nytt.

Når du kan knytte din egen stabile identifikator til ressursen du oppretter, foretrekk den fremgangsmåten.

Mønstre for mutasjoner som ikke er naturlig idempotente 

For mutasjoner som oppretter ressurser uten en forhandlerlevert nøkkel, bør du behandle dem som maksimalt én gang fra din side:

1. Lagre forespørselen før du sender den. Skriv en rad til din egen database (status pending) før nettverkskallet.
2. Send mutasjonen. Ved suksess registrerer du den returnerte ressurs-ID-en mot den ventende raden din (status committed).
3. Ikke prøv blindt på nytt ved nettverksfeil. Spør Zonos Graph for å avgjøre om ressursen ble opprettet (for eksempel ved å liste opp ressurser som er opprettet de siste minuttene for kontoen din, eller ved å spørre etter en relatert ressurs du kan korrelere mot). Prøv bare på nytt hvis du kan bekrefte at ressursen ikke finnes.
4. Bruk en unik begrensning i din egen database på hvilken forretningsnøkkel som enn representerer forespørselen, slik at en duplisert gjentakelse fra din egen applikasjon ikke kan sendes inn to ganger.

Webhook-levering skjer minst én gang 

Når du konsumerer Zonos-webhooker, bør du utforme håndterere som er idempotente — den samme hendelsen kan bli levert mer enn én gang. Deduplicer basert på hendelses-ID-en. Se Webhooker for hendelses-ID-feltet.

Hvor plattformen er på vei 

Den underliggende plattformen kjører allerede idempotensnøkkel-flyter i produksjon for faktureringsgjentakelser: nøkkelen avgrenser et gjentakelsesforsøk og forhindrer dupliserte kall til betalingsbehandleren. Vi jobber med å eksponere det samme mønsteret som et valgfritt idempotencyKey-argument på kundevendte opprettelsesmutasjoner. Når det oppgis, returnerer Graph det opprinnelige svaret for ethvert påfølgende kall med samme nøkkel innenfor et oppbevaringsvindu. Denne siden vil bli oppdatert når funksjonen er allment tilgjengelig.

Hvis standardiserte idempotensnøkler på kundevendte mutasjoner er til hinder for integrasjonen din, kontakt support.