[Gitea Loader]: Rate limit hit for ${endpoint}. Waiting ${re

Error message

[Gitea Loader]: Rate limit hit for ${endpoint}. Waiting ${retryAfter}s before retrying...

What it means

Warning logged by GiteaRepoLoader.fetchJson when the Gitea HTTP API answers 429 (rate limited). The loader reads the Retry-After header (defaulting to 60 seconds), waits that long, and recursively retries with retries+1 up to MAX_RETRIES (3). The line itself is transient back-off information; data is only lost if the limit persists after all retries.

Source

Thrown at collector/utils/extensions/RepoLoader/GiteaRepo/RepoLoader/index.js:381

      });

      if (response.status === 429) {
        if (retries >= MAX_RETRIES) {
          console.warn(
            `[Gitea Loader]: Rate limit persists for ${endpoint} after ${retries} retries. Skipping.`
          );
          return null;
        }
        const retryAfter = Number(response.headers.get("retry-after")) || 60;
        console.warn(
          `[Gitea Loader]: Rate limit hit for ${endpoint}. Waiting ${retryAfter}s before retrying...`
        );
        await this.#wait(retryAfter * 1000);
        return this.fetchJson(endpoint, retries + 1);
      }

      if (response.status === 401 || response.status === 403) {
        console.warn(
          `[Gitea Loader]: Unauthorized request for ${endpoint}. Skipping.`
        );
        return null;
      }

      if (!response.ok) {
        console.warn(
          `[Gitea Loader]: Unexpected status ${response.status} for ${endpoint}. Skipping.`
        );
        return null;
      }

      return await response.json();
    } catch (e) {
      console.error(`GiteaRepoLoader.fetchJson`, e);
      return null;
    }
  }

View on GitHub (pinned to 3aec848f28)

Solutions

Let the sync finish — the loader honors Retry-After and retries up to 3 times automatically.
Reduce scope: load a single repo or branch instead of a whole organization/group.
Raise the token's quota or use a higher-privileged personal access token on the Gitea side.
If a fronting proxy produces the 429, relax its limit or make it send a correct Retry-After header so waits are accurate.

Defensive patterns

Strategy: retry

Prevention

Schedule repo syncs off-peak and at most one concurrent job per Gitea host.
Scope loaders narrowly (one repo/branch) instead of whole organizations.
Use a token with generous quota and monitor 429 frequency in logs.
Ensure fronting proxies send an accurate Retry-After so built-in waits are effective.

When it happens

Trigger: Cloning a large Gitea repo whose branch/tree/page fetches exceed the instance's request quota; a token with a low hourly limit; a self-hosted Gitea behind nginx/traefik rate-limit rules that emit 429 with or without an accurate Retry-After header.

Common situations: Big monorepo syncs; several collectors or CI jobs hammering the same Gitea host in parallel; aggressive default rate limits on shared Gitea instances.

Related errors

AI-assisted analysis of Mintplex-Labs/anything-llm@3aec848f28 (2026-08-18). Data as JSON: /api/errors/6fc22bfb0a38f77e. Report an issue: GitHub.