Cloudflare innfører nye forsøk for Durable Objects – og skiller dem etter feilrisiko

Hvis et kall til et Durable Object mislyktes på grunn av en nettverksfeil, måtte utviklere tidligere ofte avgjøre om de skulle sende det på nytt. Fra 5. november 2026 utfører Cloudflares runtime-miljø noen av disse nye forsøkene: Det prøver automatisk på nytt ved bestemte mislykkede kall til fetch() og RPC via en stub. For applikasjonskoden blir det sentrale spørsmålet nå mer presist: Kan den aktuelle metoden trygt kjøres en gang til?

Svaret avhenger av hvor forbindelsen ble brutt. Runtime-miljøet prøver automatisk på nytt ved enkelte kall, samtidig som beskyttelsen mot dobbel kjøring beholdes som standard. Ved usikker levering bruker det samme forespørsels-ID, og objektet avviser et nytt forsøk hvis det allerede har mottatt det første. En metode som uttrykkelig er merket med retryable(), oppfører seg annerledes: Den kan kjøres igjen selv om første forsøk allerede nådde objektet. Merkingen passer derfor bare for operasjoner der gjentakelse er trygg både for tilstanden og for bivirkningene.

Hva runtime-miljøet prøver på nytt

Ifølge Cloudflares kunngjøring 5. november omfatter de nye forsøkene kall til fetch() og RPC mot Durable Objects fra en Worker eller et annet Durable Object. For kall via en stub er standarden ett første forsøk og opptil fire nye forsøk; nye forsøk starter ikke senere enn 10 sekunder etter at kallet begynte.

Forutsetningen er en feil med egenskapen .retryable. Forespørselen kan for eksempel ha nådd objektet fordi det ble startet på nytt eller flyttet. Runtime-miljøet kan også prøve igjen hvis forbindelsen ble brutt og det er uklart om objektet rakk å motta forespørselen. Hvis objektet allerede har mottatt den, avvises et nytt forsøk med samme ID. Runtime-miljøet prøver ikke på nytt ved feil som kastes av Durable Object-koden, feil med .overloaded eller HTTP-svar som 500: Dette er svar fra behandleren, ikke leveringsfeil.

Hvorfor ny levering ikke er det samme som å gjenta en operasjon

At forespørselen sendes på nytt, betyr ikke i seg selv at metoden kjøres en gang til. Når resultatet er usikkert, sender runtime-miljøet forespørselen med samme ID; hvis objektet mottok det første forsøket, avviser det det nye. I normalmodus hindrer dette at metoden kjøres flere ganger, for eksempel at en betaling belastes på nytt eller at en post opprettes igjen på grunn av én nettverksfeil.

Grensen endres når metoden merkes med retryable() fra cloudflare:durable-objects. Da kan objektet kjøre metoden på nytt hvis første forsøk kan ha begynt. Cloudflare gir to eksempler: Å angi et bestemt antall varer er idempotent; å øke antallet med én er det ikke. En gjentakelse av den første handlingen setter samme verdi, mens en gjentakelse av den andre legger til enda én vare.

Du må kontrollere mer enn den endelige tilstanden i lagringen: Se også på alle effektene metoden har. Hvis en gjentakelse oppretter en ny betaling, sender en melding eller utløser en ekstern handling, er ikke gjentakelsen trygg bare fordi tilstanden inne i Durable Object forblir den samme. Merk metoden bare når gjentakelsen ikke endrer resultatets betydning eller dupliserer bivirkninger.

Når uttrykkelig idempotens er nyttig

Å angi en verdi, lagre et tilstandsbilde eller oppdatere et felt til en kjent verdi gir ofte samme resultat ved gjentakelse. For slike metoder kan retryable() gjøre at kallet fullføres selv etter at forbindelsen brytes etter at behandlingen har begynt.

Operasjoner som «legg til», «opprett en til», «belast» og «send» krever vanligvis en annen form for beskyttelse. Før du tillater en ny kjøring, må du forsikre deg om at forretningsoperasjonen oppdager duplikater, eller er utformet slik at en gjentakelse ikke skaper en ekstra effekt. Funksjonsnavnet i seg selv garanterer ingenting: Kontroller alle tilstandsendringer og eksterne handlinger i metoden.

retryable() har en avgrenset rolle: Den tillater ny kjøring når det er umulig å fastslå om det første kallet nådde frem. Den endrer ikke hvilke feil runtime-miljøet reagerer på, og øker heller ikke antallet forsøk. Flagget gjelder funksjonen; en overstyrt eller innpakket versjon av metoden arver det ikke automatisk, med mindre også den uttrykkelig merkes.

Hva du bør kontrollere i et eksisterende prosjekt

Det mest sannsynlige stedet for en gjennomgang er egne løkker for nye forsøk rundt kall til Durable Objects. Nå kan hvert slikt forsøk også utløse runtime-miljøets nye forsøk, slik at det samlede antallet kall blir høyere enn det applikasjonen alene legger opp til. Cloudflare anbefaler å redusere antallet egne forsøk eller angi maxRetries: 0 for stubben hvis koden din styrer forsøkene.

Grensene for en bestemt stub angis ved kall til get() eller getByName(). Parameteren maxRetries angir fra null til ti nye forsøk etter det første; timeoutMs angir intervallet der nye forsøk kan starte, fra 500 til 60 000 millisekunder. Disse innstillingene gjelder kall via den aktuelle stubben. Bruk av retryable() og objektet retry krever Wrangler 4.158.0 eller nyere.

En nyttig gjennomgang stiller tre spørsmål for hvert kall: Kan det endre tilstanden mer enn én gang? Gjentar det eksterne bivirkninger? Har applikasjonen en egen policy for nye forsøk? Bestem deretter om den aktuelle stubben skal bruke standardverdiene eller egne grenser. For idempotente metoder kan du vurdere en uttrykkelig merking separat; for andre metoder bør du beholde beskyttelsen og kontrollere feilhåndteringen når resultatet av første forsøk er ukjent.

Konsekvensen: Ansvaret flyttes til metodegrensen

Automatiske nye forsøk fjerner noe av nettverkslogikken fra applikasjonskoden, men avgjørelsen om ny kjøring er forsvarlig, ligger fortsatt i selve operasjonen. Runtime-miljøet kan trygt prøve å levere forespørselen på nytt og stanse hvis det ikke vet om kallet ble utført. Utvikleren kan tillate at metoden kjøres på nytt ved uttrykkelig å bekrefte at det ikke fører til doble tilstandsendringer eller bivirkninger.

Oppdateringen bør derfor forstås som en endring i kontrakten mellom transportlaget og behandleren. Kontroller først egne løkker for nye forsøk og om bivirkninger kan gjentas; konfigurer deretter grensene for de aktuelle stubbene. Slik kan innebygd robusthet mot korte avbrudd kombineres med kontroll over operasjoner der en ny kjøring har en reell kostnad.