import type { GitXRateLimitProvider } from '../schemas/GitXRateLimitProvider';
/**
 * Latest known SCM rate-limit snapshot for a single (connector, provider, bucket) tuple.
 */
export interface GitXRateLimitEntry {
    /**
     * Provider-specific rate-limit bucket (e.g. core, search, graphql, api).
     */
    bucket?: string;
    /**
     * Connector identifier the snapshot is scoped to.
     */
    connector_id?: string;
    /**
     * Number of requests consumed in the current window. When the provider does not emit a used counter, this is derived as limit minus remaining.
     * @format int64
     */
    current_consumption?: number;
    /**
     * Epoch millis when this snapshot was last updated.
     * @format int64
     */
    last_updated_at?: number;
    /**
     * Maximum requests allowed in the current window.
     * @format int64
     */
    limit?: number;
    provider?: GitXRateLimitProvider;
    /**
     * Requests remaining in the current window.
     * @format int64
     */
    remaining?: number;
    /**
     * Epoch millis when the current window resets, as reported by the provider. UI computes the countdown as resets_at - Date.now() (clamped to zero). 0 sentinel when the provider does not emit a reset time.
     * @format int64
     */
    resets_at?: number;
    /**
     * Count of HTTP 429 responses this (connector, bucket) has received from the Git provider during the current rate-limit window — i.e., since the last provider-reported reset up to now. Effectively restarts when the window resets (see resets_at). A value of 0 means the connector is healthy; non-zero means the provider is actively throttling it. For providers that use per-second/concurrency limits rather than a windowed quota (notably Bitbucket DC / Server), this counter still increments on every 429 but limit and remaining may be -1 sentinel values.
     *
     * @format int64
     */
    too_many_requests_in_window?: number;
}