Automatisering mislyktes: sjekk før du prøver på nytt

En automatisering markerer feil, og noen foreslår å trykke «Prøv på nytt». Først er det lurt å svare på et mer konkret spørsmål: hva mangler å bli gjort? Det kan mangle handlingen, dens bekreftelse eller et senere trinn. Å gjenta hele flyten er nyttig for én av disse situasjonene og kan forverre de andre.

For en gründer eller et lite team må undersøkelsen kunne fortsette selv om den som satte opp integrasjonen ikke er til stede. Denne guiden gir en tidslinje og et skjema for å skille det verifiserte fra det ukjente. Eksemplet er fiktivt: det beskriver ikke en Frihet-hendelse og bruker ikke virkelige tjenester, kunder eller påloggingsopplysninger.

Skjermfeilen og arbeidsstatusen

En timeout indikerer at en ventetid tok slutt uten svar i tide. Alene kan den ikke si om destinasjonen lagret noe. AWS forklarer dette problemet med en forespørsel som kunne ha opprettet en ressurs selv om den som ba om det ikke mottok bekreftelse. Å løse denne usikkerheten krever å identifisere effekten og dens opprinnelse.

Arbeid med tre tilstander: bekreftet effekt, bekreftet fravær av effekt og ukjent. «Det vises ikke på skjermen min» tilhører den tredje så lenge det kan være filtre, en annen konto, en forsinket indeks eller en fortsatt aktiv utførelse. Noter også hvem som sjekket status og når: en observasjon har kontekst, ikke evig gyldighet.

En tidslinje som endrer beslutningen

Anta en flyt som oppretter en intern oppgave og deretter registrerer dens referanse i et sporingsark. Alt som følger er hypotetisk. Tidspunktene bruker samme simulerte klokke; i en reell undersøkelse behold tidssone og opprinnelse for hvert tidsstempel.

Neste skritt er å gjenopprette sporingen ved hjelp av den dokumenterte prosedyren. Å starte på nytt fra «opprett oppgave» ville berøre noe som allerede er løst. Hvis siste rad bare sa «jeg ser det ikke i arket», måtte vi fortsatt utelukke en forsinkelse, et filter eller en aktiv prosess før vi skriver der.

Operasjonsreferansen forblir stabil; forsøksidentifikatoren endres med hver utførelse. En mottatt hendelse og en opprettet oppgave har også forskjellige identiteter. Oppretthold deres relasjoner for ikke å forveksle to forsøk på samme jobb med to legitime jobber.

Lagre et skjema som en annen person kan fortsette

Start med å bevare eksisterende logger og begrense nye skrivinger med pausemekanismen som er beregnet for denne flyten. En pause gjør ikke det som er utført, ugjort, og garanterer heller ikke å stoppe forespørsler som allerede er i gang. Gå gjennom køen og ventende nye forsøk før du antar at ingen andre vil handle.

Kopier dette skjemaet til en intern logg med passende tilgang. Bruk referanser til bevis, unngå å lime inn hemmeligheter eller personlige data i delte dokumenter. Hver korreksjon skal legges til med dato, uten å slette den tidligere observasjonen.

Hendelse: [intern referanse]
Ønsket operasjon: [et enkelt konkret resultat]
Leverandør / konto / miljø: [destinasjonskontekst]
Operasjon / hendelse / forsøk: [ID-er og relasjoner]
Flytversjon: [utført versjon]
Siste bekreftede trinn: [dokumentasjon og tidspunkt med tidssone]
Effektstatus: [bekreftet / fravær bekreftet / ukjent]
Destinasjonsbevis: [referanse, spørring og synlighetsgrenser]
Fortsatt aktivt arbeid: [forespørsler, kø og ventende nye forsøk]
Vilkår for nye forsøk: [dokumentasjon, omfang og tidsvindu]
Manglende data: [nødvendig bevis for å bestemme]
Neste handling: [avgrenset spørring eller gjenoppretting]
Ansvarlig / neste gjennomgang: [person og dato]
Senere resultat: [nytt bevis, uten å overskrive det forrige]

«Fravær bekreftet» krever sterkere bevis enn et tomt søk: for eksempel en avvisning før utførelse dokumentert av destinasjonen, når andre forsøk er utelukket som årsak til effekten. Hvis du ikke kan begrunne den statusen, behold «ukjent».

Idempotensnøkkelen har grenser

Sjekk leverandørens kontrakt for den spesifikke forespørselen, kontoen og miljøet. En nøkkel som beskytter en skriving, beskytter ikke automatisk en senere varsling eller en annen tjeneste. Den kan heller ikke legges til retroaktivt til en forespørsel som allerede ble sendt uten den. Skjemaet skal lenke til relevant dokumentasjon, ikke bare si «vi har idempotens».

I Stripe gjenbruker idempotente forespørsler — API v1 det lagrede resultatet fra den første utførelsen, inkludert 500-feil. Stripe sammenligner parametere og kan slette nøkler etter minst 24 timer; gjenbruk av en slettet nøkkel starter en ny forespørsel. Deres feilguide advarer om mulige effekter etter en 500: å endre nøkkelen eller vente til den utløper beviser ikke at det er trygt å gjenta en usikker handling.

Den tidligere fristen tilhører Stripe. For en annen destinasjon, noter dens egen tidsramme, identiteten den anser som gjentatt og behandlingen av samtidige forespørsler. Hvis en gjenoppretting krever parameterendringer, behandle det som en ny beslutning, med gjennomgang av tidligere effekter.

Bestem basert på bevis, trinn for trinn

Tabellen nedenfor er et foreslått operativt kriterium, ikke en universell leverandørpolicy. Skill undersøkelsen fra autorisasjonen til å endre data.

Irreversible eller skrivinger med store konsekvenser krever menneskelig gjennomgang av den foreslåtte gjenopprettingen. Verken en nøkkel eller en grønn knapp gir en «nøyaktig én gang»-garanti for hele arbeidsflyten.

Sjekk også hvem som vil prøve på nytt

Det kan hende at automatiseringsverktøyet, API-klienten og leverandøren har egne forsøk på nytt. I Stripe-webhooks kansellerer ikke en manuell gjensending de automatiske nye forsøkene; i tillegg kan hendelser gjentas og komme ut av rekkefølge. Å sende en hendelse på nytt er heller ikke det samme som å gjenta en API-skriving idempotent: det er forskjellige mekanismer.

Før du lukker skjemaet, sjekk den nåværende statusen for destinasjonen, de gjenstående trinnene og forsøkene som kan komme senere. Definer hvem som skal observere neste utførelse. Å lukke skjemaet er ikke det samme som å løse arbeidet: hvis et ukjent resultat gjenstår, hold hendelsen åpen med ansvarlig og gjennomgangsdato.

Deretter kan du vurdere om flyten fortjener å forbli automatisert med kriteriet om å eliminere, automatisere og delegere (på engelsk). Hvis den kobler til Frihet, se utviklerdokumentasjonen og integrasjonskatalogen for å finne det tilsvarende grensesnittet. Oppbevar dette skjemaet sammen med flyten: den neste personen skal kunne finne den siste kontrollerte statusen uten å måtte rekonstruere den fra en chat.

Tekniske kilder konsultert 14. september 2026. Skjemaene, beslutningene og DEMO-referansene er egne didaktiske forslag; de er ikke instruksjoner for å utføre endringer i en reell tjeneste.