import type { Job } from 'bullmq';
import { JobCleanStatus, JobCounts, JobStatus, QueueAdapterOptions, QueueJobOptions } from '../../typings/app';
import { BullMQAdapter } from './bullMQ';
import type { QueueProLike } from './bullMQProTypes';
export declare class BullMQProAdapter extends BullMQAdapter {
    readonly isPro = true;
    private readonly proQueue;
    private snapshotCache;
    constructor(queue: QueueProLike, options?: Partial<QueueAdapterOptions>);
    getJobCounts(): Promise<JobCounts>;
    getJobs(jobStatuses: JobStatus[], start?: number, end?: number): Promise<Job[]>;
    addJob(name: string, data: any, options: QueueJobOptions): Promise<Job<any, any, string>>;
    clean(jobStatus: JobCleanStatus, graceTimeMs: number): Promise<void>;
    empty(): Promise<void>;
    obliterate(): Promise<void>;
    pause(): Promise<void>;
    resume(): Promise<void>;
    promoteAll(): Promise<void>;
    /**
     * Runs a mutation with the cached reading dropped on both sides of it. Dropping it beforehand
     * is not enough on its own: a poll landing while the write is still in flight would cache the
     * queue as it was and serve that for a whole TTL.
     */
    private withSnapshotReset;
    private invalidateSnapshot;
    /**
     * The current reading of the queue, taken at most once every `SNAPSHOT_TTL_MS`.
     *
     * Counting jobs and listing them need the same group listing, and the counts decide where the
     * listing is cut, so both come out of one reading -- otherwise a group that changes status
     * between the two calls is counted twice, or a page skips jobs the count promised.
     *
     * It is the in-flight promise that is cached, so callers arriving together -- two browser tabs
     * polling, say -- share one reading instead of racing to replace each other's.
     */
    private getSnapshot;
    private readQueue;
    /**
     * Every group of one status, with the number of jobs it holds.
     *
     * Note this deliberately does not use `getGroupsCountByStatus()`, which counts *groups*
     * rather than the jobs inside them -- folding that into job counts reported one job per group
     * (issue #1346). Only `getGroupsByStatus()` names the groups, so counting the jobs in them
     * costs a listing of every group on every reading; that is what the snapshot TTL bounds.
     *
     * The range is passed explicitly rather than left to the getter's default: the totals are
     * only right if every group is listed.
     */
    private listGroups;
    /**
     * Jobs in one group, asked for outright. Needed on bullmq-pro < 7.46.3, where
     * `getGroupsByStatus()` returns ids alone: assuming one job per group would understate the
     * counts and, since those counts also decide what to read from each group, hide every job in
     * the group but the first. Versions old enough to lack `getGroupJobsCount()` as well keep
     * that one-job-per-group approximation.
     */
    private countGroupJobs;
    private getRelevantGroupStatuses;
    /**
     * A page of jobs taken from the groups, in the order the statuses were asked for.
     *
     * Which slice of which group to read follows from the counts already in the snapshot, so the
     * ranges are all worked out first and the groups then read at once: a page spanning ten
     * groups costs one round trip's latency rather than ten.
     */
    private fetchJobsFromGroups;
}
export type { JobProLike, QueueProLike } from './bullMQProTypes';