import { QueryClient, type QueryClientConfig } from '@tanstack/react-query';
/**
 * Whether a response status is worth asking for again.
 *
 * 5xx and the three transient 4xx statuses are; every other 4xx is not, and
 * neither is anything below 400 — a 304 reaching the error path is a caching
 * problem, not a flaky one.
 */
export declare function isRetryableHttpStatus(status: number): boolean;
/**
 * Whether a rejected query or mutation is worth retrying.
 *
 * A rejection carrying no status is retried by default: a DNS failure, a
 * dropped connection, a CORS refusal, an abort, or a middleware that threw
 * leaves no evidence beyond the request not completing, and treating an
 * unrecognised rejection as fatal would make a single dropped socket a visible
 * error.
 *
 * `ZodResponseValidationError` is the exception, and the reason this is not a
 * bare `isHttpRequestError` check. It carries no status because
 * `createZodResponseMiddleware` rejects *after* a 2xx arrived and parsed — the
 * request completed, and the body it returned does not match the schema. That
 * verdict is a property of the deployed server, so asking again produces the
 * same mismatch two round trips later: exactly the cost this module's `retry`
 * exists to avoid on a 422.
 *
 * Both checks narrow on `name` rather than `instanceof`, so they still hold
 * when a consumer's module graph contains two copies of this package.
 *
 * Exported so a consumer can keep this status policy while changing how many
 * times it asks again: `retry: (count, error) => count < 5 &&
 * isRetryableError(error)` is five retries, so six attempts.
 */
export declare function isRetryableError(error: unknown): boolean;
/**
 * The retry predicate {@link createQueryClient} installs, in react-query's own
 * `(failureCount, error)` shape. `failureCount` is the number of failures
 * *before* this attempt, so it is 0 on the first rejection.
 *
 * Exported so a consumer can wrap it rather than restate it — dropping an
 * application-specific error out of the policy, say:
 *
 * ```ts
 * retry: (count, error) =>
 *   isSessionExpired(error) ? false : shouldRetryRequest(count, error)
 * ```
 */
export declare function shouldRetryRequest(failureCount: number, error: unknown): boolean;
/**
 * A `QueryClient` with defaults suited to a data-dense application, in place of
 * react-query's, which are tuned for a document-shaped app:
 *
 * - **`refetchOnWindowFocus: false`.** Alt-tabbing back to a dashboard should
 *   not reload every panel under the cursor. Freshness is the business of
 *   `staleTime` and explicit invalidation, both of which the app controls.
 * - **A status-aware `retry`** — see {@link shouldRetryRequest}. React-query
 *   retries every rejection three times, so a 422 costs four round trips to
 *   report a validation error the server already decided on the first.
 *
 * Mutations are deliberately left un-retried — react-query's default, and the
 * right one, because a POST that reached the server may well have applied
 * before the failure and this package cannot tell which.
 *
 * Everything else is left at react-query's default deliberately, `staleTime`
 * most of all: how long a given screen may show a stale number is a product
 * decision, and a package-level guess would be wrong quietly.
 *
 * `config` is react-query's own `QueryClientConfig` and every field of it wins.
 * The merge is per-option rather than wholesale, so overriding one default
 * keeps the others:
 *
 * ```ts
 * // Keeps `refetchOnWindowFocus: false`; replaces only the retry policy.
 * const queryClient = createQueryClient({
 *   defaultOptions: { queries: { retry: 5 } },
 * });
 * ```
 *
 * A `queries` key present with the value `undefined` is *not* an override: it
 * is dropped before the merge, so the else-branch of
 * `retry: cond ? false : undefined` leaves the shipped policy standing rather
 * than reverting it to react-query's `retry ?? 3`.
 */
export declare function createQueryClient(config?: QueryClientConfig): QueryClient;