import { FlowProducer, Job, Queue, type RedisClient } from 'bullmq';
import { AppJobScheduler, JobCleanStatus, JobCounts, JobSchedulerRepeatOptions, JobSchedulerUpdateResult, JobStatus, MetricsType, QueueAdapterOptions, QueueDefaultJobOptions, QueueJobOptions, QueueMetrics, QueueWorker, RedisStats, Status } from '../../typings/app';
import { BaseAdapter } from './base';
export declare class BullMQAdapter extends BaseAdapter {
    private queue;
    constructor(queue: Queue, options?: Partial<QueueAdapterOptions>);
    getRedisInfo(): Promise<string | null>;
    private resolveRedisClient;
    getDatastoreStats(): Promise<RedisStats | null>;
    private get hasPausedState();
    getName(): string;
    getWorkers(): Promise<QueueWorker[] | null>;
    clean(jobStatus: JobCleanStatus, graceTimeMs: number): Promise<void>;
    addJob(name: string, data: any, options: QueueJobOptions): Promise<Job<any, any, string>>;
    getJob(id: string): Promise<Job | undefined>;
    getJobs(jobStatuses: JobStatus[], start?: number, end?: number): Promise<Job[]>;
    getJobCounts(): Promise<JobCounts>;
    getJobLogs(id: string): Promise<string[]>;
    getMetrics(type: MetricsType, start?: number, end?: number): Promise<QueueMetrics>;
    isPaused(): Promise<boolean>;
    pause(): Promise<void>;
    resume(): Promise<void>;
    empty(): Promise<void>;
    obliterate(): Promise<void>;
    promoteAll(): Promise<void>;
    removeJobScheduler(id: string): Promise<boolean>;
    getJobSchedulers(): Promise<Omit<AppJobScheduler, 'queueName'>[]>;
    getJobSchedulersCount(): Promise<number>;
    get supportsJobSchedulerUpdate(): boolean;
    updateJobScheduler(id: string, repeat: JobSchedulerRepeatOptions): Promise<JobSchedulerUpdateResult>;
    /**
     * What the dashboard can say about a scheduler's runs, all of it worked out from the ids
     * BullMQ derives, `repeat:<schedulerId>:<scheduled millis>`.
     *
     * The next run is the delayed job waiting at `scheduler.next`. BullMQ stores no last-run time,
     * but it creates that delayed job the moment the previous run moves to active, so the job's
     * `timestamp` is when the previous run started. `iterationCount` of 1 means the job came from
     * the application's own upsert rather than from a run, and a scheduler past its limit or end
     * date has no pending job left at all.
     */
    private getSchedulerRuns;
    /**
     * The previous run's id, but only when it can be named and the job is still there. Interval
     * schedules fire exactly `every` milliseconds apart, so the previous id follows from the next
     * one; a cron pattern would have to be parsed to say the same, which is not worth a dependency
     * for a job that `removeOnComplete` has usually deleted anyway.
     */
    private findLastRunId;
    private schedulerRunId;
    getStatuses(): Status[];
    getJobStatuses(): JobStatus[];
    getClient(): Promise<RedisClient | null>;
    getFlowProducer(): Promise<FlowProducer | null>;
    getQueuePrefix(): string | undefined;
    /**
     * Fully prefixed Redis key for one of the queue's sets, for example `bull:MyQueue:completed`.
     * Exposed for @bull-board/metrics, which scans the completed and failed sorted sets
     * directly rather than paging whole Job objects through getJobs.
     */
    getQueueKey(set: string): string;
    getGlobalConcurrency(): Promise<number | null>;
    getQueueDefaultJobOptions(): QueueDefaultJobOptions;
    setGlobalConcurrency(concurrency: number): Promise<void>;
}