429 Túl sok kérés: mit jelent és hogyan kell kezelni

Az API akkor ad 429 Too Many Requests vissza, ha az alkalmazás több kérelmet küldött, mint amennyit az API engedélyez egy adott időszakban. Maga a kérés rendben van. Túl gyakran küldte el, ezért az API visszautasította a kérést. Ha megvárja, és újra elküldi, az általában sikerül. A válasz gyakran tartalmaz egy fejlécet Retry-After , amely jelzi, hogy mennyi ideig kell várnia. További információ: RFC 6585, 4. szakasz.

Minden API másként valósítja meg a kéréskorlátokat. Az állapotkód, a fejlécek és a hibatörzs mind eltérőek, így az egyik API-t megfelelően kezelő kód rosszul kezeli a következőt.

API Állapot Hogyan állapíthatja meg, hogy mennyi ideig kell várni Vigyázz a következőre:
GitHub 403 vagy 429 retry-after ha van ilyen, ellenkező esetben x-ratelimit-reset (UTC epoch-másodpercek), ha a(z) x-ratelimit-remaining értéke 0, egyébként legalább 1 perc A 403 lehet sebességkorlát vagy hiányzó engedély. Olvassa el a fejléceket, hogy megkülönböztesse őket.
OpenAI 429 retry-after Néhány 429-es, például a credit_balance_exhausted, azt jelenti, hogy az újrapróbálkozás nem fog segíteni. Ellenőrizze a error.codeelemet.
Anthropic 429 retry-after A költési korlát miatti 429 esetén nincs retry-after, és mindaddig sikertelen marad, amíg a hozzáférés nem folytatódik. A túlterhelt API 529 értékkel tér vissza, nem pedig 429 értékkel.
Microsoft Graph 429 Retry-After (másodperc) A korlátozások szolgáltatásonként eltérőek, például SharePoint és Outlook.

A 429 kezelése

  1. Döntse el, hogy újra próbálkozik-e egyáltalán. Ha a hiba azt jelzi, hogy a kvóta, a kreditek vagy a költségkeret fel van használva, az újrapróbálkozás nem fog segíteni. Mondja el a felhasználónak, és figyelmeztesse magát.
  2. Várjon annyi ideig, amennyit az API kér. Ha a válasz tartalmazza a(z) Retry-After értéket, várjon ennyi ideig. Ez vagy másodpercek száma, vagy egy HTTP-dátum. Ha az API inkább sebességkorlátozási fejléceket használ, például GitHubx-ratelimit-reset, várja meg a visszaállítás időpontját.
  3. Ellenkező esetben hátráljon. Az API-ból származó tipp nélkül próbálkozzon újra exponenciális késleltetéssel és véletlenszerű jitterrel, és néhány kísérlet után állítsa le.
  4. Tájékoztassa a felhasználót arról, mi történik. „Elfoglalt, újrapróbálkozás 5 másodperc múlva” jobb, mint egy soha véget nem érő spinner.
  5. Lassíts a következő 429 előtt. Ha az API sebességkorlát-fejléceket küld, a fennmaradó szám használatával szabályozhatja a kérések ütemezését.
async function fetchWithRetry(url, options, attempts = 3) {
  for (let attempt = 1; ; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === attempts) {
      return response;
    }
    const retryAfter = response.headers.get('retry-after');
    const waitMs = retryAfter
      ? (isNaN(retryAfter) ? new Date(retryAfter) - Date.now() : retryAfter * 1000)
      : 2 ** attempt * 1000 + Math.random() * 1000;
    await new Promise(resolve => setTimeout(resolve, Math.max(waitMs, 0)));
  }
}

Sok SDK helyetted újrapróbálkozik 429-es válasz esetén. Az OpenAI Python SDK például alapértelmezés szerint 2 alkalommal próbálkozik újra, a .NET standard resilience handler pedig háromszor próbálkozik újra, és figyelembe veszi a Retry-After beállítást. Amikor az SDK kimeríti az újrapróbálkozási lehetőségeket, a kód hibát kap, így továbbra is szükség van egy tervre.

Annak tesztelése, hogy az alkalmazás kezeli-e a 429-et

Fejlesztés közben ritkán látja a 429-et. Az API gyors, ön az egyetlen felhasználó, és a tesztadataid mennyisége kicsi. Így az, ahogyan a 429-kezelést teszteli, dönti el, hogy a felhasználók előtt megtalálja-e a hibákat.

Approach Mit talál? Amit kihagy
Várjon az élesítésre Tényleges hibák Minden, amíg egy felhasználó rá nem kattint
Mockold az API-t a tesztekben, vagy hagyd, hogy a kódoló ügynök írja meg a mockot Hogy az újrapróbálkozási ág lefut-e Az API valós állapotkódjai, fejlécei és hibatörzsei, valamint az SDK újrapróbálkozési szabályzata. Az alkalmazásnak egy csak tesztelési kapcsolóra is szüksége van a mock eléréséhez.
Hívja a valódi API-t, amíg korlátozni nem kezdi a kéréseit Valós viselkedés Nem válthat ki 429-es hibát igény szerint, és a valós kvótát használja fel
Elfogja az alkalmazás valós forgalmát, és igény szerint 429-es HTTP-válaszokat ad vissza Valós URL-címek, valódi SDK- és újrapróbálkozési szabályzat, valamint az API saját 429-es formátuma Az alkalmazásban semmi sem változik, így a kódodat nem teszteli elkülönítve. Arra valók az egységtesztek.

Próbálja ki a saját alkalmazásában

A Dev Proxy elfogja az alkalmazás kéréseit a választott API-khoz, és 429-et ad vissza az API saját fejléceivel és hibaformátumával, miközben az alkalmazás folyamatosan meghívja a valódi URL-címeket. Azt is jelzi, hogy az alkalmazás mikor próbálkozik újra a Retry-After letelte előtt.

Töltse le annak az API-nak a beállításkészletét, amelyet az alkalmazása hív, és indítsa el vele a Dev Proxyt:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"
API Preset
GitHub github-rate-limiting
OpenAI openai-throttling
Anthropic anthropic-throttling
Microsoft Graph (OneDrive és SharePoint: /drive, /shares, /sites) microsoft-graph-rate-limiting

Ezután futtassa az alkalmazást a szokásos módon, és figyelje meg, hogy mit csinál. A Dev Proxy telepítéséhez lásd: Dev Proxy beállítása.

További lépések

Teszteld, hogy az alkalmazás megfelelően kezeli-e a limitálást

Lásd még

  • Utolsó frissítés időpontja: