Prøve igjen etter en feil? Avklar om handlingen allerede er utført

For en markedsavdeling er et nytt teknisk forsøk sjelden ment som en ny bestilling. Målet er fortsatt én oppfølgingsoppgave, én kupong eller én kundemelding. Likevel kan en automatisk omstart skape en ny effekt dersom arbeidsflyten ikke vet hva som allerede har skjedd.

Et tidsavbrudd betyr at den som sendte forespørselen, sluttet å vente. Det er ikke bevis for at mottakeren stoppet. Før dere aktiverer automatisk gjenoppretting, bør dere avtale hvordan handlinger identifiseres, fremdrift lagres, resultat bekreftes og tvil behandles. Dette kan ikke løses med en bedre AI-prompt alene.

Følg resultatet, ikke bare feilmeldingen

Se for dere et oppdiktet eksempel som ikke er gjennomført: En kampanjeforespørsel skal opprette en oppfølgingsoppgave i CRM og deretter sende en e-post. CRM-systemet lagrer oppgaven, men svaret kommer aldri frem. Hele arbeidsflyten kjøres om, og dermed risikerer dere to oppgaver for samme bestilling.

Det riktige neste steget er å finne ut om den første oppgaven finnes. Kan dere slå den opp med en pålitelig referanse, lagrer dere oppgavens ID fra CRM-systemet og bruker det bekreftede resultatet videre. Deretter fortsetter dere fra det uavklarte trinnet, etter å ha kontrollert også e-postens status. Et akseptert e-postanrop er ikke bevis for levering. Uten bekreftelse eller dokumentert duplikatbeskyttelse settes saken på vent.

1. Stopp før handlingen er påbegynt: Et nytt forsøk kan tillates etter avtalt policy.
2. Bekreftet fullført: Bruk det lagrede resultatet uten å utføre handlingen på nytt.
3. Usikkert utfall: Avklar med mottakeren eller bruk dokumentert beskyttelse for samme handling.

Skill mellom hendelsen, handlingen og forsøket

En webhook er et automatisk varsel om en hendelse. Slike varsler kan leveres flere ganger. Shopify anbefaler idempotent behandling eller registrering av webhook-ID for å kjenne igjen duplikate leveringer. Ulike abonnementer kan samtidig ha ulike webhook-ID-er for samme hendelse. Leveringsidentiteten forteller derfor ikke alene hvilken forretningshandling dere skal utføre.

Be implementøren gi hver tilsiktede handling en stabil ID som ikke inneholder kundens personopplysninger. Denne beholdes ved nye forsøk, mens hvert forsøk får sin egen ID. En bevisst ny handling trenger ny identitet og godkjenning. Slik kan dere stoppe duplikater uten å fjerne legitime, separate aktiviteter.

Lagre handlings-ID, kilde og hendelse, ønsket handling, godkjent innhold med versjon, status, antall forsøk, mottakerreferanse, tidspunkter, ansvarlig og neste beslutning. Sensitive kundeopplysninger trengs ikke for å vise hvordan registreringen fungerer. Den må være tilgjengelig også når selve kjøringen er over, slik at neste operatør kan forstå saken.

Be om dokumenterte grenser for beskyttelsen

Idempotens betyr at gjentakelse av samme tilsiktede handling ikke tilfører en ny effekt, innenfor systemets dokumenterte vilkår. Undersøk hvilke handlinger mottakeren beskytter, hvor lenge beskyttelsen varer, og hvordan feil og endrede opplysninger behandles. Et beskyttet nytt forsøk krever samme nøkkel og parametere innenfor gyldighetsperioden.

Stripe er et nyttig API-eksempel. For POST-forespørsler som støttes, gir samme idempotensnøkkel den første lagrede statusen og svaret tilbake, også feil. Endrede parametere med samme nøkkel gir feil. Nøkler kan fjernes etter minst 24 timer; gjenbruk etter fjerning blir en ny forespørsel. Resultater lagres først når endepunktet begynner utførelsen, og valideringsfeil og samtidighetskonflikter har andre regler. Dette er Stripe-spesifikke vilkår, ikke en generell lagringstid eller et forslag om betalingsautomatisering.

Et lokalt spørsmål om handlingen er ferdig, løser heller ikke alt. To samtidige prosesser kan begge få svaret nei. Mottakeren kan dessuten fullføre før lokal status blir lagret. Be derfor om en atomisk reservasjon, altså én udelelig reservasjon, eller en unik begrensning i databasen, sammen med mottakerens beskyttelse eller avstemming mot mottakeren. Verken registrering av ID eller logging etterpå gir noen garanti.

Shopify Flows egendefinerte handlingsendepunkter viser hvorfor gjentakelser må forventes: Systemet venter opptil ti sekunder på svar, lukker forbindelsen og sender igjen senere. action_run_id kan brukes til å kjenne igjen kjøringen. Shopify fjerner ikke dermed duplikater i mottakerens arbeid, og ti sekunder er ingen generell regel for webhooks eller CRM.

Godkjenning må gjelde det innholdet som faktisk brukes

AI kan utforme utkast eller klassifisere en feil. Faste regler i arbeidsflyten og en navngitt ansvarlig må styre handlinger med konsekvenser. Bruk samme godkjente innhold ved nye forsøk. Ny tekst kan endre budskapet og krever ny vurdering. Avklar først den tidligere handlingens usikre utfall.

Et godkjenningspunkt hindrer ikke i seg selv gjentakelser. Når en LangGraph-flyt gjenopptas etter en pause med interrupt(), kjøres det berørte trinnet, noden, fra begynnelsen. Eksterne endringer før avbruddet kan derfor gjentas. Dokumentasjonen anbefaler idempotente operasjoner eller å flytte og skille ut slike handlinger. Oppdeling gjør fremdriften lettere å følge, men beskytter ikke alene mot alle senere feil.

Hvis mottakeren ikke kan bekrefte resultatet eller hindre duplikater, stopp og send saken til en navngitt person. Avtal grenser for antall forsøk og ventetid mellom dem etter mottakerens dokumenterte regler. Unngå uendelige forsøk eller ett felles antall for alle tjenester.

Bestill en pilot med synlige akseptansekriterier

Følgende er foreslåtte prøvesituasjoner, ikke utførte tester eller en garanti for nøyaktig én effekt på tvers av vilkårlige systemer.

1. Vanlig vellykket kjøring: Handlingen bekreftes, og mottakerens referanse lagres.
2. Samme hendelse to ganger: Beskyttede duplikattilfeller gir én tilsiktet ekstern handling og gjenbruker dokumentasjonen.
3. Tidsavbrudd etter at mottakeren har lykkes: Eksisterende resultat finnes; uavklart status holdes til vurdering.
4. To samtidige forsøk: Reservasjon og mottakerbeskyttelse hindrer en ekstra effekt i det beskyttede tilfellet.
5. Gjenopptakelse etter godkjenning: Godkjent innhold beholdes, og fullførte trinn hoppes over.
6. Sen gjentakelse etter lagringsperioden: Ikke stol på gammel nøkkel; avstem resultatet eller sett saken på vent.

Mål hendelser, forsøk, bekreftede eksterne effekter, uavklarte saker og operatørens tidsbruk ved gjenoppretting hver for seg. Slik skiller dere teknisk merarbeid fra flere kundehendelser.

MindVerves automatiseringstjeneste kartlegger utløsere, inn- og utdata, ansvar, regler for manglende data og feil, prøvesituasjoner og driftsinstruksjoner. AI Workflow Launch konfigurerer én avtalt arbeidsflyt med verktøyvalg, tester av representative situasjoner og feil, gjenbrukbare briefer og prompter, dokumentasjon, opplæring og overlevering. Lisenser, API-bruk og ekstra integrasjoner er ikke inkludert; løpende vedlikehold avtales separat.