Ett misslyckat svar betyder inte alltid att åtgärden misslyckades. Klienten kan tappa anslutningen efter att servern har registrerat en betalning, skickat ett mejl eller skapat en post. Innan du låter AI lägga till automatiska omförsök måste du därför sätta tidsgränser, klassificera vilka fel som kan provas igen och göra den berörda operationen idempotent.
Huvudfallet döljer integrationens verkliga kontrakt
En genererad klient börjar ofta med en begäran, en kontroll av statuskoden och en tolkning av svaret. Det räcker i en demonstration, men lämnar flera driftfrågor obesvarade: Hur länge får anropet vänta? Vad händer om svaret inte går att tolka? Kan samma operation köras igen? Hur vet du om leverantören redan hann utföra den?
Be därför modellen redovisa felkontraktet före implementationen. Ange vilka operationer som bara läser, vilka som förändrar data och vilka konsekvenser en dubblett får. Utan den uppdelningen är ett generellt råd som ”försök tre gånger” farligt.
Ett bibliotek med automatisk retry aktiveras för alla metoder. Ett läsanrop kan då bli stabilare, medan ett skrivande anrop riskerar att skapa två beställningar eller skicka samma meddelande flera gånger. Omförsök är en affärsregel, inte bara en nätverksinställning.
Sätt timeout i varje lager som kan vänta
Utan en explicit tidsgräns kan en worker, webbrequest eller kökonsument bli kvar mycket längre än resten av systemet tillåter. Sätt en total tidsbudget som utgår från användarflödet och fördela den mellan anslutning, svar och eventuell bearbetning. Ett internt anrop får inte vänta längre än den överordnade begäran som ska använda resultatet.
Logga att en timeout inträffade och vilken operation det gällde, men lägg inte API-nycklar, personuppgifter eller hela svarskroppar i loggen. Timeouten ska dessutom ge ett eget felutfall så att den går att skilja från avvisade uppgifter och programmeringsfel.
Försök bara igen när felet och operationen tillåter det
Omförsök passar tillfälliga fel: en bruten anslutning, överbelastning eller en uttrycklig signal från tjänsten att klienten ska vänta. De passar inte valideringsfel, nekad behörighet eller en resurs som faktiskt saknas. Följ API:ets dokumenterade felkontrakt och respektera en angiven väntetid när leverantören skickar en sådan.
Ett lyckat omförsök ska mätas som ett tecken på instabilitet, inte döljas som en vanlig framgång. Annars märker teamet först problemet när alla försök börjar misslyckas.
Idempotens gör dubbla anrop ofarliga
Idempotens betyder här att samma logiska operation kan tas emot flera gånger utan att effekten upprepas. Klienten skapar en stabil nyckel för operationen och återanvänder den vid varje försök. Mottagaren lagrar nyckeln tillsammans med resultatet och returnerar samma resultat om nyckeln kommer igen.
Nyckeln måste höra till affärshändelsen, inte till det enskilda HTTP-försöket. Om en beställning får en ny nyckel vid varje retry finns inget dubblettskydd. På serversidan behövs dessutom en unik restriktion eller motsvarande atomiskt skydd; en separat ”finns den redan?”-kontroll kan släppa igenom två samtidiga anrop.
Tre frågor innan du gör ett skrivande anrop
- Vad identifierar den logiska operationen? Exempelvis beställningens interna id, inte en ny slumpnyckel per nätverksförsök.
- Var sparas utfallet? Samma nyckel ska kunna returnera samma svar även om det första svaret aldrig nådde klienten.
- Vad händer vid parallella anrop? Databasens eller tjänstens atomiska skydd ska avgöra vinnaren, inte timing i applikationskoden.
Webhooks levereras minst en gång, inte exakt en gång
Behandla inkommande webhooks som potentiella dubbletter och som händelser som kan komma i annan ordning än väntat. Verifiera avsändarens signatur mot den råa begäran enligt leverantörens dokumentation, registrera händelsens id och kvittera först när händelsen är säkert sparad för fortsatt behandling.
Själva affärsarbetet bör kunna köras om utan dubbel effekt. Om bearbetningen misslyckas efter att händelsen sparats kan en kö eller ett återhämtningsjobb ta över. Om allt görs synkront före svaret ökar risken att avsändaren hinner göra en ny leverans medan den första fortfarande arbetar.
Testa felvägarna utan att vänta på riktiga driftfel
En granskningsprompt för den genererade integrationen
Granska integrationen utan att ändra kod ännu.
Lista varje externt anrop och ange: tidsgräns, vilka fel som kan provas igen, högsta antal försök, total tidsbudget och om operationen förändrar data.
För varje skrivande operation: visa vilket idempotensskydd som finns och vad som händer om servern genomför åtgärden men svaret försvinner.
För inkommande webhooks: kontrollera signaturverifiering, dubblettskydd, parallell leverans och återhämtning efter avbruten bearbetning.
Avsluta med saknade tester och rangordna riskerna. Anta inte att en statuskod är säker att prova igen utan stöd i API-kontraktet.
Låt modellen peka ut luckorna, men verifiera förslagen mot tjänstens faktiska dokumentation och den klientversion som används i projektet. Precis som vid val av beroenden kan modellens minnesbild vara äldre än det API du integrerar mot.