GitHub API のレート制限を超えました: その意味と対処方法

GitHubは、アプリが送信できる REST API 要求の数を制限します。 制限を超えると、GitHub は、制限がリセットされるか待機時間が経過するまで、403 または 429 の状態で要求を拒否します。 GitHubには 2 種類の制限があります。1 時間あたりの要求に対する主な制限と、急増を防ぐセカンダリ制限です。 レート制限されている間もアプリがリクエストを送信し続けると、GitHub があなたのインテグレーションを禁止する可能性があります。 詳細については、「REST API のレート制限」を参照してください。

GitHub のレート制限とは

GitHubは、予告なしにセカンダリの制限を変更できます。また、その制限にどの程度近づいているかを確認する方法はありません。

すべての応答には、プライマリ制限の現在の状況を示すヘッダーが含まれています。

GitHub のレート制限に対処する方法

1. レート制限とアクセス許可エラーを見分けます。 GitHub は、トークンにアクセスがない場合にも 403 を返します。 応答に retry-afterがなく、 x-ratelimit-remaining が 0されておらず、メッセージにレート制限が記載されていない場合は、アクセス許可の問題です。 再試行しないでください。
2. 最初に retry-after に従います。 ヘッダーが存在する場合は、その秒数待ちます。
3. それ以外の場合は、リセットを待ちます。 x-ratelimit-remainingが0の場合は、x-ratelimit-resetの時刻まで再試行しないでください。
4. そうでない場合は、1 分以上待ってください。 どちらのヘッダーもないセカンダリ制限の場合、GitHub は少なくとも 1 分間待機し、再試行が失敗するたびにさらに長く待つよう求めます。 設定した回数の再試行後に停止し、エラーを発生させます。
5. 使い切ってしまう前にペースを落とします。x-ratelimit-remaining と x-ratelimit-reset を使用して、要求のペースを設定します。 GitHubによって制限が変更される可能性があるため、正確な残りの数に関するロジックを構築しないでください。 x-ratelimit-* ヘッダーは、GET /rate_limit エンドポイントではなく、信頼できる情報源です。

async function githubWaitMs(response, attempt) {
  if (response.status !== 403 && response.status !== 429) {
    return null;
  }
  const retryAfter = response.headers.get('retry-after');
  if (retryAfter) {
    return Number(retryAfter) * 1000;
  }
  if (response.headers.get('x-ratelimit-remaining') === '0') {
    const resetMs = Number(response.headers.get('x-ratelimit-reset')) * 1000;
    return Math.max(resetMs - Date.now(), 0);
  }
  const { message = '' } = await response.clone().json().catch(() => ({}));
  if (response.status === 429 || /rate limit/i.test(message)) {
    return 60_000 * 2 ** attempt;
  }
  // A 403 without rate limit signals is a permission problem: don't retry
  return null;
}

呼び出し元は、関数が数値を返したときに再試行し、数回試行した後に停止します。

アプリがGitHubレート制限を処理することをテストする方法

開発中にGitHubレート制限に達することはめったにありません。 いくつかの要求を送信すると、1 時間あたり 5,000 件が無限にあるように感じられます。 つまり、レート制限の対応をどのようにテストするかによって、ユーザーがバグを発見する前に自分で発見できるかどうかが決まります。

アプリで試す

Dev Proxyは、アプリのapi.github.comへの要求をインターセプトし、GitHubスタイルのレート制限応答を返しますが、アプリは実際のURLを呼び出し続けます。 github-rate-limiting プリセットでは、要求は 1 時間あたり 60 回の上限に対してカウントされ、x-ratelimit-* ヘッダーを送信し、上限に達すると API rate limit exceeded を含む 429 を返します。それまでは、要求は GitHub に送られ、実際の上限に対してもカウントされます。

プリセットをダウンロードし、それを使用して開発プロキシを起動します。

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

セカンダリ制限をテストするには、代わりに同じフォルダーから devproxyrc-secondary.json を使用して Dev Proxy を起動します。 セカンダリ レート制限 429 を retry-after ヘッダーを伴ってランダムに返します。

その後、通常どおりにアプリを実行し、アプリがどのように動作するかを確認します。 開発プロキシをインストールするには、「 開発プロキシの設定」を参照してください。

次のステップ

参照

• 429 リクエストが多すぎます: その意味と対処方法
• Retry-After ヘッダー: 再試行するまでの待機時間
• レート制限とは
• レート制限を処理する方法
• レート制限 API 応答をシミュレートする
• RateLimitingPlugin