import { SearchType } from "../storage.mjs";
import { ResolveExtraFn } from "./run-query.mjs";
/**
 * Host-supplied reader: return the materialised rollup's rows for an
 * `(id, tenant, slice)`, in the exact shape the live extra produces, or `null`
 * when no rollup exists (first sync, never built, stale) so the overlay
 * declines and the resolver falls back to the live query. Typically wired with
 * `readLatestRollup` + a `read_parquet` of the pointer.
 *
 * `dateRange` is the request window. `query_canonical_variants` is full-history
 * (its grouping/variant metrics span all dates), but `buildExtrasQueries`
 * windows the live `canonicalExtras` to the requested range — so for a narrow
 * window the reader MUST decline (return `null`) rather than attach
 * out-of-window variantCount/canonicalName/variants. A common rule: serve only
 * when the request window covers full history.
 */
interface RollupRowsReader {
  (opts: {
    id: string;
    ctx: {
      userId: string;
      siteId: string;
    };
    searchType?: SearchType;
    dateRange: {
      startDate: string;
      endDate: string;
    };
  }): Promise<Array<Record<string, unknown>> | null>;
}
/**
 * Build a {@link ResolveExtraFn} that serves resolver extras from materialised
 * rollups when one is mapped for the extra's key, else returns `null` to fall
 * back to the live SQL. Pure wiring around the host's `readRollupRows`.
 */
declare function createRollupExtrasOverlay(readRollupRows: RollupRowsReader): ResolveExtraFn;
export { RollupRowsReader, createRollupExtrasOverlay };