export declare class GitHubRateLimitError extends Error {
    readonly name = "GitHubRateLimitError";
    readonly rateLimitResetAt: string | null;
    constructor(message: string, rateLimitResetAt?: string | null);
}
export declare const RATE_LIMIT_MAX_RETRIES = 3;
export declare const RATE_LIMIT_TOTAL_BACKOFF_CAP_MS = 5000;
export declare const RATE_LIMIT_BASE_BACKOFF_MS = 250;
export declare const SECONDARY_RATE_LIMIT_FLOOR_MS = 60000;
export type Sleep = (milliseconds: number) => Promise<void>;
export type GithubRestRequestInfo = {
    method?: string;
    path?: string;
};
export declare const realSleep: Sleep;
export declare const hasRateLimitSignals: (status: number, headers: Headers, bodyText: string) => boolean;
/**
 * Returns true when the status code is a transient, infrastructure-level
 * GitHub REST API failure (500/502/503/504) that GitHub's own documentation
 * acknowledges as retryable.
 */
export declare const isTransientServerErrorStatus: (status: number) => boolean;
/**
 * Returns true when the response indicates a secondary (content-creation)
 * rate limit, detected by two signals:
 *   1. Response body matches SECONDARY_RATE_LIMIT_BODY_PATTERN — covers both
 *      the current "secondary rate limit" phrasing and the historical
 *      "abuse detection mechanism" phrasing GitHub used before standardising
 *      its error messages.  GitHub's REST API documentation does not guarantee
 *      exact response body wording.
 *   2. A retry-after header is present.
 *
 * Secondary rate limits require a minimum 60-second wait before any retry,
 * which is incompatible with the 5-second primary-limit budget cap.
 *
 * Note: x-ratelimit-remaining=0 with a future x-ratelimit-reset and no
 * retry-after is the primary hourly-quota exhaustion signature, NOT a
 * secondary rate limit.  That case is handled separately in
 * fetchWithGitHubRateLimitRetry to avoid contaminating the shared circuit
 * breaker state file with a primary-quota event.
 */
export declare const isSecondaryRateLimit: (headers: Headers, bodyText: string) => boolean;
/**
 * Computes how long to wait before retrying after a secondary rate limit
 * response.  Respects retry-after and x-ratelimit-reset when present, and
 * enforces a minimum of SECONDARY_RATE_LIMIT_FLOOR_MS (60 s) regardless of
 * what the headers say, as required by the GitHub REST API documentation.
 * The 5-second primary-limit budget cap does NOT apply here.
 */
export declare const computeSecondaryRateLimitBackoffMs: (headers: Headers, nowMs: number) => number;
export declare const computeRateLimitResetIso: (headers: Headers) => string | null;
export declare const computeBoundedBackoffMs: (headers: Headers, attempt: number, elapsedMs: number) => number;
/**
 * Wraps a GitHub API request with rate-limit-aware retry logic.
 *
 * Two classes of rate limit are handled differently:
 *
 * Secondary rate limits (content-creation blocks) — detected by
 * `isSecondaryRateLimit` — require a minimum 60-second wait which exceeds
 * the primary-limit budget cap.  When `retryOnSecondaryRateLimit` is false
 * (the default, appropriate for interactive console operations) the function
 * returns the error response immediately without retrying, so exactly one
 * request is spent and the caller can surface the reset timestamp to the
 * user.  When true, up to RATE_LIMIT_MAX_RETRIES retries are performed with
 * `computeSecondaryRateLimitBackoffMs` (60-second floor, no budget cap).
 *
 * Circuit breaker (content-creating requests only):
 * When `isContentCreating` is true, the function checks a shared on-disk
 * state file before issuing the request.  If another process has already
 * recorded an active secondary rate limit block, the request is not issued
 * and a synthetic 403 response is returned immediately, naming the reset
 * time.  When a secondary rate limit is detected in a response, the block
 * is written to the shared state file so every other process on the host
 * benefits from the discovery.
 *
 * Primary rate limits, and transient server errors (500/502/503/504) on
 * non-content-creating requests, follow the same sub-second exponential
 * schedule bounded by RATE_LIMIT_TOTAL_BACKOFF_CAP_MS.  A transient server
 * error on a content-creating request, and any other failure, is returned
 * immediately without retrying.
 */
export declare const fetchWithGitHubRateLimitRetry: (request: () => Promise<Response>, sleep?: Sleep, now?: () => number, retryOnSecondaryRateLimit?: boolean, isContentCreating?: boolean, stateFilePath?: string, requestInfo?: GithubRestRequestInfo) => Promise<Response>;
//# sourceMappingURL=githubRateLimitRetry.d.ts.map