import { UpdateScheduledTaskInput } from '@vendure/common/lib/generated-types'; import { Cron } from 'croner'; import { Injector } from '../../common'; import { ScheduledTask } from '../../scheduler/scheduled-task'; import { SchedulerStrategy, TaskReport } from '../../scheduler/scheduler-strategy'; /** * @description * The default {@link SchedulerStrategy} implementation that uses the database to * execute scheduled tasks. This strategy is configured when you use the * {@link DefaultSchedulerPlugin}. * * @since 3.3.0 * @docsCategory scheduled-tasks */ export declare class DefaultSchedulerStrategy implements SchedulerStrategy { private connection; private injector; private intervalRef; private readonly tasks; private pluginOptions; private runningTasks; private staleTaskService; init(injector: Injector): void; destroy(): Promise; registerTask(task: ScheduledTask): void; executeTask(task: ScheduledTask): (job?: Cron) => Promise; getTasks(): Promise; getTask(id: string): Promise; updateTask(input: UpdateScheduledTaskInput): Promise; triggerTask(task: ScheduledTask): Promise; private checkForManuallyTriggeredTasks; private entityToReport; private ensureAllTasksAreRegistered; /** * Attempts to acquire a lock for the given task. * * For databases that support pessimistic locking (PostgreSQL, MySQL, MariaDB), * we use SELECT ... FOR UPDATE to ensure only one worker can acquire the lock. * This is necessary because PostgreSQL's MVCC can allow multiple concurrent * UPDATE statements to succeed when using a simple "UPDATE ... WHERE lockedAt IS NULL" pattern. * * For databases that don't support pessimistic locking (SQLite, SQL.js), * we fall back to the atomic UPDATE approach which works correctly for single-connection scenarios. */ private tryAcquireLock; private ensureTaskIsRegistered; }