Je agent probeert opnieuw. Is de actie al uitgevoerd?

Je agent vraagt een rapport aan. Het rapport wordt opgeslagen, maar het antwoord bereikt de agent niet. Die probeert opnieuw en maakt een tweede rapport. Het zichtbare probleem zat in de bevestiging. Door de schrijfactie te herhalen, veranderde onzekerheid in een duplicaat. Een timeout vertelt op zichzelf niet welk onderdeel is afgerond.¹

Geef één bedoelde actie een vaste identiteit

Een idempotency key herkent dezelfde bedoelde actie bij een volgende poging. De server kan daarmee een herhaling herkennen en een vastgelegd resultaat teruggeven. Maak de code één keer voor die actie en behoud hem bij een herhaling. Een nieuwe code bij elke poging maakt die herkenning onmogelijk. AWS beschrijft dit verschil tussen opnieuw proberen en een nieuwe bedoeling in zijn uitleg over API-ontwerp.¹

De code heeft ook een afbakening nodig. Aanvragen van twee gebruikers mogen niet per ongeluk dezelfde identiteit delen. Leg vast bij welke gebruiker of organisatie de code hoort, hoelang je hem bewaart en wanneer inhoud nog als dezelfde aanvraag geldt. Neem geen persoonsgegevens of andere gevoelige informatie op in de code. De documentatie van Stripe geeft hiervan een concreet API-voorbeeld, geen afspraak die iedere dienst hetzelfde uitvoert.²

Sla resultaat en ontvangstbewijs samen op

Voor deze les heeft Forenta een klein synthetisch experiment met SQLite uitgevoerd. Het schrijft een rapport en legt de aanvraagcode in dezelfde lokale database vast. De eerste aanroep wordt opgeslagen. Daarna gooit het voorbeeld bewust het antwoord weg. Zonder bescherming levert dezelfde aanvraag bij herhaling twee rapportregels op. Met bescherming verwijst de herhaling naar de bestaande regel en blijft het totaal één. Dit is een test van ons eigen voorbeeld, geen opname van Claude Code of Codex die een workflow uitvoert.

Het beschermde voorbeeld bewaart naast de code een hash van de aangeleverde inhoud. Dezelfde code met andere inhoud geeft een conflict. Het voorbeeld retourneert dus niet stilzwijgend een resultaat dat bij een andere aanvraag hoort. Het resultaat en de identiteit worden binnen één transactie opgeslagen, met een unieke databasebeperking op de code. De SQLite-documentatie beschrijft deze lokale transactiegrens en het gedrag bij schrijfacties.³

Test het foutpad voordat je op succes vertrouwt

Een geslaagde eerste aanvraag is niet genoeg. Herhaal exact dezelfde aanvraag nadat je hebt nagebootst dat het antwoord verloren ging. Vergelijk de opgeslagen uitvoer, aanvraagcode en beide teruggegeven resultaten. In ons voorbeeld verwacht je één rapport en hetzelfde ontvangstbewijs. Verander daarna de inhoud terwijl je de code behoudt. Dan verwacht je een expliciet conflict zonder extra rapport.

Voer vervolgens dezelfde actie gelijktijdig uit via onafhankelijke workers. Eerst lezen en daarna schrijven kan fout gaan als de database die beslissing niet als één geheel afdwingt. Het vastgelegde experiment met één proces bewijst geen veiligheid bij gelijktijdige of verdeelde uitvoering. Die uitkomst blijft onbekend totdat jouw implementatie een eigen test heeft. Voeg ook een onderbroken aanvraag en herstel na herstart toe als die situaties bij de workflow horen.¹ ³

Een lokaal ontvangstbewijs heeft een grens

Een databaseregel beschermt op zichzelf geen e-mail, betaling of publicatie bij een ander systeem. De externe dienst kan de actie afronden voordat het lokale proces succes vastlegt. Eerst een ontvangstbewijs opslaan kan het omgekeerde probleem geven: het bewijs bestaat, maar de externe actie is nooit uitgevoerd. Dit zijn verschillende foutgevallen. De outbox-uitleg van AWS behandelt het probleem van schrijven naar twee systemen. Ook daarbij vraagt dubbele berichtbezorging om ontvangers die herhalingen herkennen.⁵

Gebruik waar mogelijk de eigen afspraken van de ontvangende dienst over idempotentie en statuscontrole. Controleer hoelang codes geldig blijven, wat de dienst na een fout teruggeeft, hoe inhoud wordt vergeleken en hoe gelijktijdige aanvragen worden afgehandeld. Zelfs tussen API-versies kunnen die afspraken verschillen. Neem een bewaartermijn of foutgedrag van een andere leverancier niet zonder controle over.²

HTTP maakt daarnaast onderscheid tussen idempotente methoden en willekeurige applicatieacties. Een client hoort een niet-idempotente actie niet automatisch te herhalen zonder grond om te weten dat dit veilig is of dat de eerste aanvraag niet is toegepast. De naam retry is op zichzelf geen onderbouwing.⁴

Maak van de controle een toetsbaar plan

Gebruik de prompt hierboven met Claude Code of Codex om één afgebakende workflow te onderzoeken. Vraag eerst om bestandslocaties, het huidige foutgedrag en een testvoorstel voordat je wijzigingen toestaat. Houd productieschrijfacties en berichten buiten die eerste stap. Het antwoord van je coding agent is een voorstel: bekijk het bewijs en voer de onschuldige tests zelf uit.

Wil je het plan nog laten beoordelen, dan analyseert Forge de tekst die je aanlevert. Plak de bedoelde actie, de grens van de herhaling, aannames en acceptatiecontroles. Forge leest of controleert je repository niet automatisch. Een tekstanalyse kan niet vaststellen dat jouw externe dienst een herhaalde aanvraag veilig afhandelt.