Automatisering fejlede: tjek dette, før du prøver igen

En automatisering viser en fejl, og nogen foreslår at trykke på «Genforsøg». Før det er det bedre at besvare et mere konkret spørgsmål: hvad mangler at blive gjort? Det kan være handlingen, dens bekræftelse eller et efterfølgende trin. At gentage hele flowet er kun nyttigt i én af disse situationer og kan forværre de andre.

For en grundlægger eller et lille team skal undersøgelsen kunne fortsætte, selvom den, der opsatte integrationen, ikke er til stede. Denne vejledning leverer en tidslinje og en rapport til at skelne mellem det bekræftede og det ukendte. Eksemplet er fiktivt: det beskriver ikke en hændelse hos Frihet og bruger ikke virkelige tjenester, kunder eller adgangsoplysninger.

Skærmfejlen og arbejdsstatus

En timeout indikerer, at en ventetid sluttede uden svar i tide. Alene kan den ikke afsløre, om destinationen gemte noget. AWS forklarer dette problem med en anmodning, der kunne have oprettet en ressource, selvom anmoderen ikke modtog bekræftelse. At løse denne usikkerhed kræver identifikation af effekten og dens oprindelse.

Arbejd med tre tilstande: bekræftet effekt, bekræftet manglende effekt og ukendt. «Det vises ikke på min skærm» tilhører den tredje, så længe der kan være filtre, en anden konto, et forsinket indeks eller en stadig aktiv udførelse. Notér også hvem der kontrollerede status og hvornår: en observation har kontekst, ikke evig gyldighed.

En tidslinje, der ændrer beslutningen

Antag et flow, der opretter en intern opgave og derefter registrerer dens reference på et sporingsark. Alt det følgende er hypotetisk. Tiderne bruger det samme simulerede ur; i en rigtig undersøgelse skal du bevare tidszone og oprindelse for hvert tidsstempel.

Næste skridt er at genoprette sporingen ved hjælp af den dokumenterede procedure. At genstarte fra «opret opgave» ville røre ved noget, der allerede er løst. Hvis den sidste række kun sagde «jeg kan ikke se det på arket», skulle vi stadig udelukke en forsinkelse, et filter eller en aktiv proces, før vi skriver der.

Operationsreferencen forbliver stabil; forsøgsidentifikatoren ændres ved hver udførelse. En modtaget hændelse og en oprettet opgave har også forskellige identiteter. Bevar deres relationer for ikke at forveksle to forsøg på det samme arbejde med to legitime arbejdsopgaver.

Gem en rapport, som andre kan fortsætte

Start med at bevare eksisterende logfiler og begrænse nye skrivninger med den pausemekanisme, der er beregnet til dette flow. En pause fortryder ikke det udførte og garanterer heller ikke at stoppe anmodninger, der allerede er i gang. Gennemgå køen og afventende genforsøg, før du antager, at ingen andre vil handle.

Kopier denne rapport til en intern log med passende adgang. Brug referencer til beviser, undgå at indsætte hemmeligheder eller personlige data i delte dokumenter. Hver rettelse skal tilføjes med dato, uden at slette den tidligere observation.

Hændelse: [intern reference]
Ønsket handling: [et enkelt, konkret resultat]
Udbyder / konto / miljø: [destinationens kontekst]
Operation / hændelse / forsøg: [ID'er og relationer]
Flowversion: [udført version]
Sidste bekræftede trin: [dokumentation og tidspunkt med tidszone]
Effektstatus: [bekræftet / bekræftet fraværende / ukendt]
Destinationsbevis: [reference, forespørgsel og synlighedsgrænser]
Stadig aktivt arbejde: [anmodninger, kø og afventende genforsøg]
Betingelser for genforsøg: [dokumentation, omfang og tidsvindue]
Manglende data: [nødvendigt bevis for at beslutte]
Næste handling: [begrænset forespørgsel eller genoprettelse]
Ansvarlig / næste gennemgang: [person og dato]
Efterfølgende resultat: [nyt bevis, uden at overskrive det tidligere]

«Bekræftet fraværende» kræver et stærkere bevis end en tom søgning: f.eks. et afslag før udførelsen dokumenteret af destinationen, hvor andre forsøg er udelukket som kilde til effekten. Hvis du ikke kan begrunde denne status, skal du bevare «ukendt».

Idempotensnøglen har begrænsninger

Kontroller leverandørens kontrakt for den specifikke anmodning, konto og miljø. En nøgle, der beskytter en skrivning, beskytter ikke automatisk en efterfølgende notifikation eller en anden service. Den kan heller ikke tilføjes retroaktivt til en anmodning, der allerede er sendt uden den. Rapporten skal linke til den gældende dokumentation, ikke bare sige «vi har idempotens».

Hos Stripe genbruger idempotente anmodninger — API v1 det gemte resultat fra den første udførelse, inklusive 500-fejl. Stripe sammenligner parametre og kan slette nøgler efter mindst 24 timer; genbrug af en slettet nøgle starter en ny anmodning. Deres fejlvejledning advarer om mulige effekter efter en 500: at ændre nøglen eller vente på, at den udløber, beviser ikke, at det er sikkert at gentage en usikker handling.

Ovenstående frist tilhører Stripe. For en anden destination skal du notere dens eget tidsvindue, den identitet den anser for gentaget, og håndteringen af samtidige anmodninger. Hvis en genoprettelse kræver ændring af parametre, skal den behandles som en ny beslutning med en gennemgang af tidligere effekter.

Træf beslutninger baseret på beviser, trin for trin

Den følgende tabel er et foreslået operationelt kriterium, ikke en universel leverandørpolitik. Adskil undersøgelsen fra godkendelsen til at ændre data.

Irreversible eller skrivninger med stor påvirkning kræver menneskelig gennemgang af den foreslåede genoprettelse. Hverken en nøgle eller en grøn knap tilbyder en «nøjagtigt én gang»-garanti for hele processen.

Tjek også hvem der vil genforsøge

Automatiseringsværktøjet, API-klienten og leverandøren kan have deres egne genforsøg. Hos Stripe-webhooks annullerer en manuel genafsendelse ikke automatiske genforsøg; desuden kan hændelser gentages og ankomme ude af rækkefølge. At sende en hændelse igen er heller ikke det samme som at gentage en API-skrivning idempotent: det er forskellige mekanismer.

Før du lukker rapporten, skal du kontrollere destinationens aktuelle status, de afventende trin og de forsøg, der måtte komme efterfølgende. Definer hvem der skal observere den næste udførelse. At lukke rapporten er ikke det samme som at løse opgaven: hvis der forbliver et ukendt resultat, skal du holde hændelsen åben med ansvarlig person og gennemgangsdato.

Derefter kan du gennemgå, om flowet fortjener at forblive automatiseret med kriteriet fjern, automatiser og deleger (på engelsk). Hvis flowet er forbundet med Frihet, start med udviklerdokumentationen og integrationskataloget for at finde den tilsvarende grænseflade. Gem denne rapport sammen med flowet: den næste person skal kunne finde den senest kontrollerede status uden at rekonstruere den fra en chat.

Tekniske kilder konsulteret den 14. september 2026. Rapporter, beslutninger og DEMO-referencer er egne didaktiske forslag; de er ikke instruktioner til at udføre ændringer i en reel service.