Webhook genforsøgshåndtering er et tilstandsstyringsproblem. En afsender kan levere igen efter en timeout, selv når modtageren har udført noget arbejde. Hvis hvert forsøg skaber en ny billet eller gentager en ændring, forstørrer integrationen en almindelig netværksfejl til en operationel hændelse.
Skelne leveringsforsøg fra forretningseffekter
Definer en leveringsnøgle ved hjælp af udbyderens dokumenterede identitet og abonnementet eller lejers omfang. Definer særskilt forretningseffekten, såsom opdatering af en eksisterende godkendelsesfund. Flere gyldige hændelser kan legitimt relatere til det samme fund, mens gentagen levering af en hændelse ikke bør anvende dens effekt to gange.
GitHubs webhook-vejledning siger, at anmodede omleveringer bevarer X-GitHub-Delivery. Det råder også til at svare med en 2XX inden for ti sekunder og overveje asynkron behandling. Behandl dem som GitHub-specifik dokumenteret adfærd. Lov ikke, at hver udbyder automatisk prøver igen eller bruger den samme timeout; bekræfte sin faktiske leveringspolitik og gendannelsesrute for mistet levering.
Bekræft ved den rigtige grænse
Bekræft først begivenheden, registrer derefter accepteret arbejde varigt, før du anerkender succes. Behandle dyrt arbejde fra en kø. Hvis varig accept mislykkes, skal du ikke sende et successvar, blot fordi parsing lykkedes. Omvendt skal du ikke holde en forbindelse åben, før en lang downstream-undersøgelse er afsluttet, når udbyderen kræver et hurtigt svar.
Brug tilstande som i kø, behandler, afventer igen, komplet og dødt bogstav. Spor antallet af forsøg og næste genforsøgstid. Et arbejdsnedbrud kan efterlade et behandlingskrav opgivet, så definer en sikker leasing- eller gendannelsesregel. Beskyt unikke og tilstandsovergange med databasebegrænsninger eller transaktioner i stedet for en læs-og-skriv-kontrol, der er sårbar over for samtidige leveringer.
Design effekter, der kan prøves igen
Til eksterne opkald skal du bruge en understøttet idempotensnøgle eller en stabil målidentitet, hvor den er tilgængelig. Når en timeout efterlader resultatet usikkert, skal du læse eller afstemme målet, før du gentager en bivirkning. Hvis downstream-API'en ikke kan tilbyde idempotens, skal du dokumentere den resterende duplikatrisiko og tilføje en kompenserende gennemgangssti.
Antag, at en verificeret levering er varig i kø, men dens succesrespons går tabt. En senere anmodet omlevering skulle finde den samme leveringstilstand, ikke oprette en anden billet, blot fordi en anden HTTP-anmodning ankom. Antag separat, at arbejderen kalder en billet-API og timeout, efter at denne API kan have oprettet billetten. Køens leveringsdeduplikering alene kan ikke løse denne downstream-usikkerhed: inspicer målet eller brug dets understøttede idempotensnøgle, før oprettelsen gentages.
Disse er hypotetiske fejlstier, ikke en eksekveret kø, virtuel urtest eller nøjagtig-engangsgaranti. Test samtidige dubletter, arbejderafbrydelse, en opgivet behandlingslejekontrakt og begrænset udtømning ved hjælp af den faktiske lager- og downstream-kontrakt. En genstand med dødt bogstav bør beholde sikre beviser og kræve en kontrolleret gentagelse, efter at årsagen er rettet, i stedet for stille nulstilling af forsøgstællingen.
Luk løkken ved opbrugt arbejde
Brug afgrænsede genforsøg med backoff og gældende hastighedsgrænsesignaler. GitHub REST bedste praksis forklare hastighedsgrænse-bevidst adfærd for denne API; anvende den faktiske downstream-tjenestes kontrakt på produktionen. Flyt gentagne gange fejlende varer til en kontrolleret dødbogstavskø og advare den ansvarlige operatør med sikre beviser og det næste trin.
Adskil transportfejl, der kan gentages, fra permanente skema- eller godkendelsesfejl. Genafspilning af en uautoriseret anmodning på ubestemt tid vil ikke rette dens tilladelse. Behold tilstrækkeligt med identitet og resultatbeviser til at forklare hver begivenheds endelige tilstand, og giv en bevidst operatørgenafspilningsprocedure efter korrektion. Overvåg det ældste arbejde i kø, prøv udmattelse igen og uafklarede resultater, ikke kun antallet af vellykkede HTTP-svar. Ingen live-udbyderens genforsøgsadfærd eller EmailAuth evne er demonstreret her.