Rubriken Retry-After: hur länge du ska vänta innan du försöker igen

Retry-After är ett HTTP-svarshuvud som talar om för din app hur länge den ska vänta innan den skickar nästa begäran. Värdet är antingen ett antal sekunder eller ett HTTP-datum. När ett API skickar det är det det mest tillförlitliga svaret på "när kan jag försöka igen?" eftersom det kommer från servern som avvisade din begäran. Mer information finns i RFC 9110, avsnitt 10.2.3.

Hur Retry-After ser ut

Rubriken har två format. Din app måste hantera båda.

Format Example Vad det innebär
Seconds Retry-After: 120 Vänta 120 sekunder (2 minuter) från när du fick svaret. Värdet är ett icke-negativt heltal.
HTTP-datum Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Skicka inte begäran igen före denna tidpunkt. Datumet är alltid i GMT.

Servrar skickar Retry-After med följande statuskoder:

Status Vad Retry-After betyder Source
429 Too Many Requests Hur länge ska du vänta innan du skickar en ny begäran. Servern kan innehålla den. RFC 6585, avsnitt 4
503 Service Unavailable Hur länge tjänsten förväntas vara otillgänglig. Servern kan innehålla det. RFC 9110, avsnitt 15.6.4
413 Content Too Large Om tillståndet är tillfälligt bör servern säga efter hur lång tid tillståndet upphör. RFC 9110, avsnitt 15.5.14
Valfri omdirigering 3xx Minsta tid att vänta innan du följer omdirigeringen. RFC 9110, avsnitt 10.2.3

Rubriken är valfri. Vissa API:er använder sina egna headers i stället. GitHub meddelar dig till exempel när gränsen återställs med x-ratelimit-reset. Mer information finns i GitHub API-gränsen för begäranden har överskridits.

Hantera Retry-After

  1. Läs båda formaten. Om värdet är ett tal är det sekunder. Annars parsar du det som ett datum och subtraherar den aktuella tiden. Om datumet redan har passerat kan du försöka igen direkt.
  2. Vänta minst så länge som rubriken anger. Att försöka igen tidigare ger dig vanligtvis en annan 429 eller 503. Vissa API:er fortsätter att räkna dina förfrågningar medan de begränsar dig, så tidiga återförsök kan göra väntetiden längre. Se till exempel Microsoft Graph-vägledning om throttling.
  3. Gå tillbaka till backoff med jitter när headern saknas. Dubbla väntetiden efter varje misslyckat försök, lägg till en slumpmässig mängd så att många klienter inte försöker igen vid samma tidpunkt och begränsa väntetiden.
  4. Begränsa dina återförsök. Efter några försök, returnera felet till anroparen.
  5. Kontrollera att ett nytt försök kan hjälpa. Vissa API:er returnerar 429 när dina krediter eller din utgiftsgräns är slut. Att vänta löser inte det. Se OpenAI insufficient_quota och credit_balance_exhausted som exempel.
function retryDelayMs(response, attempt) {
  const value = response.headers.get('retry-after');
  if (value) {
    const seconds = Number(value);
    const ms = Number.isNaN(seconds) ? Date.parse(value) - Date.now() : seconds * 1000;
    if (!Number.isNaN(ms)) {
      return Math.max(ms, 0);
    }
  }
  // No usable header: exponential backoff with jitter, capped at 30 seconds
  return Math.random() * Math.min(30_000, 1_000 * 2 ** attempt);
}

Många SDK:er hanterar Retry-After åt dig, men bara tills återförsöken tar slut. Då får koden felet.

SDK Vad det gör som standard
.NET standardhanterare för resiliens Försök igen vid svaren 408, 429 och 5xx upp till 3 gånger med exponentiell backoff och jitter. Den använder Retry-After för fördröjningen eftersom standardvärdet för ShouldRetryAfterHeader är true.
Microsoft Graph SDKs Använd Retry-After när den finns och falla tillbaka på exponentiell backoff när den inte gör det. Begäranden i en JSON-batch försöks inte igen automatiskt.
OpenAI Python SDK Försöker igen vid anslutningsfel och svaren 408, 409, 429 och 5xx 2 gånger med en kort exponentiell fördröjning. Ange max_retries för att ändra det.

Kontrollera SDK:s dokumentation för den exakta policyn och testa vad som händer när det senaste omförsöket misslyckas.

Så här testar du att appen hanterar Retry-After

Du får sällan ett Retry-After medan du utvecklar, och när du får det kan du inte kontrollera dess värde. Så hur du testar detta avgör om du hittar buggarna innan dina användare gör det.

Approach Det här hittar du Vad du saknar
Vänta tills produktionen är klar Faktiska fel Allt, tills en användare träffar den
Mocka API:et i dina tester eller låt kodningsagenten skriva mocken Om koden parsar huvud Om din riktiga HTTP-klient eller SDK väntar tillräckligt länge och vad API:et faktiskt skickar. Din app behöver också en testflagga för att nå mocken.
Anropa det verkliga API:et tills det hastighetsbegränsar dig Faktiskt beteende Du kan inte utlösa ett strypt svar när du vill, och du förbrukar din faktiska kvot
Fånga upp appens verkliga trafik och returnera strypda svar på begäran Om din riktiga SDK och återförsöksprincip väntar så länge som huvudet säger Ingenting i din app ändras, så den testar inte din kod isolerat. Spara det till enhetstesterna.

Prova det i din app

Dev Proxy fångar upp appens begäranden till de API:er som du väljer och returnerar 429 svar med en Retry-After header, medan appen fortsätter att anropa de verkliga URL:erna. RetryAfterPlugin kommer ihåg när varje begränsad begäran kan göras på nytt. Om appen anropar samma URL före den tiden rapporterar Dev Proxy den och begränsar begäran igen. Plugin-programmet spårar 429 endast svar.

I felfilen för GenericRandomErrorPlugin anger du Retry-After värdet för ett 429 svar till @dynamicoch Dev Proxy fyller i antalet sekunder och spårar det åt dig.

Om du vill prova det laddar du ned en förinställning som använder båda plugin-program och startar Dev Proxy med den:

devproxy config get openai-throttling
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"

Kör sedan appen som vanligt och se vad den gör. Information om hur du installerar Dev Proxy finns i Installera Dev Proxy.

Nästa steg

Testa så att min applikation hanterar strypning korrekt

Se även

  • Uppdaterades senast