Automatisering mislukt: controleer dit vóór een nieuwe poging

Een automatisering geeft een foutmelding en iemand stelt voor om op «Opnieuw proberen» te klikken. Daarvoor is het handig om een concretere vraag te beantwoorden: wat moet er nog gebeuren? Het kan de actie, de bevestiging ervan of een latere stap zijn die ontbreekt. Het herhalen van de volledige workflow is nuttig voor één van die situaties en kan de andere verergeren.

Voor een oprichter of een klein team moet het onderzoek kunnen doorgaan, zelfs als degene die de integratie heeft opgezet er niet is. Deze gids biedt een tijdlijn en een formulier om onderscheid te maken tussen wat is geverifieerd en wat onbekend is. Het voorbeeld is fictief: het beschrijft geen incident van Frihet en maakt geen gebruik van echte diensten, klanten of inloggegevens.

De fout op het scherm en de werkstatus

Een timeout geeft aan dat een wachttijd is geëindigd zonder een tijdige reactie. Op zichzelf kan het niet bepalen of de bestemming iets heeft opgeslagen. AWS legt dit probleem uit met een verzoek dat een resource had kunnen creëren, zelfs als de aanvrager geen bevestiging ontving. Het oplossen van deze onzekerheid vereist het identificeren van het effect en de oorzaak ervan.

Werk met drie statussen: effect bevestigd, afwezigheid van effect bevestigd en onbekend. «Verschijnt niet op mijn scherm» behoort tot de derde zolang er filters, een ander account, een achterstallige index of een nog actieve uitvoering kunnen zijn. Noteer ook wie de status heeft gecontroleerd en hoe laat: een observatie heeft context, geen eeuwige geldigheid.

Een tijdlijn die de beslissing verandert

Stel dat een workflow een interne taak creëert en vervolgens de referentie ervan vastlegt in een trackingblad. Alles wat volgt is hypothetisch. De tijden gebruiken dezelfde gesimuleerde klok; in een echt onderzoek behoudt u de tijdzone en herkomst van elke markering.

De volgende stap is het herstellen van de tracking via de gedocumenteerde procedure. Opnieuw beginnen bij «taak maken» zou iets raken dat al is opgelost. Als de laatste rij alleen zou zeggen «ik zie het niet op het blad», zouden we nog steeds een vertraging, een filter of een actief proces moeten uitsluiten voordat we daar iets schrijven.

De referentie van de bewerking blijft stabiel; de poging-ID verandert bij elke uitvoering. Een ontvangen gebeurtenis en een gemaakte taak hebben ook verschillende identiteiten. Behoud hun relaties om twee pogingen van hetzelfde werk niet te verwarren met twee legitieme taken.

Bewaar een formulier dat iemand anders kan voortzetten

Begin met het bewaren van bestaande logboeken en het beperken van nieuwe schrijfbewerkingen met het pauzemechanisme dat voor die workflow is voorzien. Een pauze maakt uitgevoerde acties niet ongedaan en garandeert ook niet het stoppen van reeds lopende verzoeken. Controleer de wachtrij en de openstaande herhaalpogingen voordat u aanneemt dat niemand anders actie zal ondernemen.

Kopieer dit formulier naar een intern logboek met de juiste toegang. Gebruik verwijzingen naar bewijsmateriaal en vermijd het plakken van geheimen of persoonlijke gegevens in gedeelde documenten. Elke correctie moet met datum worden toegevoegd, zonder de vorige observatie te wissen.

Incident: [interne referentie]
Gewenste bewerking: [één specifiek resultaat]
Leverancier / account / omgeving: [bestemmingscontext]
Bewerking / gebeurtenis / pogingen: [ID's en relaties]
Workflowversie: [uitgevoerde versie]
Laatst bevestigde stap: [bewijs en tijdstip met tijdzone]
Effectstatus: [bevestigd / afwezig bevestigd / onbekend]
Bewijs uit het doelsysteem: [referentie, zoekopdracht en beperkingen van het zicht]
Nog actief werk: [verzoeken, wachtrij en openstaande herhaalpogingen]
Afspraken over herhaalpogingen: [documentatie, bereik en tijdvenster]
Ontbrekend gegeven: [bewijs nodig om te beslissen]
Volgende actie: [gegevens opvragen of afgebakend herstel]
Verantwoordelijke / volgende beoordeling: [persoon en datum]
Vervolgresultaat: [nieuw bewijs, zonder het vorige te overschrijven]

«Afwezig bevestigd» vereist sterker bewijs dan een lege zoekopdracht: bijvoorbeeld een door het doelsysteem vastgelegde afwijzing vóór uitvoering, waarbij andere pogingen als oorzaak zijn uitgesloten. Als u die status niet kunt rechtvaardigen, behoud dan «onbekend».

De idempotentiesleutel heeft beperkingen

Controleer het contract van de leverancier voor de specifieke aanvraag, account en omgeving. Een sleutel die een schrijfbewerking beschermt, beschermt niet automatisch een latere melding of een andere service. U kunt de sleutel ook niet achteraf toevoegen aan een verzoek dat al zonder die sleutel is verzonden. Het formulier moet naar de toepasselijke documentatie linken, niet alleen zeggen «we hebben idempotentie».

Bij Stripe hergebruiken idempotente verzoeken — API v1 het opgeslagen resultaat van de eerste uitvoering, inclusief 500-fouten. Stripe vergelijkt parameters en kan sleutels na minimaal 24 uur verwijderen; het hergebruiken van een verwijderde sleutel start een nieuw verzoek. Hun foutengids waarschuwt voor mogelijke effecten na een 500: het wijzigen van de sleutel of wachten tot deze verloopt, bewijst niet dat het veilig is om een onzekere actie te herhalen.

De voorgaande termijn is van Stripe. Noteer voor een ander doelsysteem het eigen tijdvenster, de identiteit die als herhaald wordt beschouwd en de behandeling van gelijktijdige verzoeken. Als een herstelactie het wijzigen van parameters vereist, behandel dit dan als een nieuwe beslissing, met herziening van de eerdere effecten.

Beslis op basis van bewijs, stap voor stap

De volgende tabel is een voorgestelde operationele richtlijn, geen universeel leveranciersbeleid. Scheid het onderzoek van de autorisatie om gegevens te wijzigen.

Onomkeerbare of impactvolle schrijfbewerkingen vereisen menselijke controle van het voorgestelde herstel. Noch een sleutel, noch een groene knop biedt een garantie van «exact één keer» voor het hele traject.

Controleer ook wie het opnieuw zal proberen

De automatiseringstool, de API-client en de leverancier kunnen hun eigen herhaalpogingen hebben. Bij Stripe-webhooks annuleert een handmatige herverzending de automatische herhaalpogingen niet; bovendien kunnen gebeurtenissen zich herhalen en buiten volgorde aankomen. Het opnieuw verzenden van een gebeurtenis is ook niet gelijk aan het op idempotente wijze herhalen van een API-schrijfbewerking: het zijn verschillende mechanismen.

Voordat u het formulier sluit, controleert u de huidige status van de bestemming, de openstaande stappen en de pogingen die later kunnen arriveren. Bepaal wie de volgende uitvoering zal observeren. Het sluiten van het formulier is niet gelijk aan het oplossen van het werk: als er een onbekend resultaat overblijft, houd dan het incident open met verantwoordelijke en beoordelingsdatum.

Daarna kunt u bekijken of de workflow het verdient om geautomatiseerd te blijven met het criterium van verwijderen, automatiseren en delegeren (in het Engels). Als de workflow met Frihet is verbonden, raadpleeg dan de ontwikkelaarsdocumentatie en de integratiecatalogus om de corresponderende interface te vinden. Bewaar dit formulier naast de workflow: de volgende persoon moet de laatst gecontroleerde status kunnen vinden zonder deze vanuit een chat te reconstrueren.

Technische bronnen geraadpleegd op 14 september 2026. De formulieren, beslissingen en DEMO-referenties zijn eigen didactische voorstellen; het zijn geen instructies om wijzigingen in een echte service uit te voeren.