// File generated from our OpenAPI spec by Stainless. See CONTRIBUTING.md for details.

import { APIResource } from '../../resource';
import { isRequestOptions } from '../../core';
import * as Core from '../../core';
import * as SchedulesAPI from './schedules';
import * as DeploymentsAPI from './deployments';

export class Schedules extends APIResource {
  /**
   * Create Deployment Schedules
   */
  create(
    id: string,
    params: ScheduleCreateParams,
    options?: Core.RequestOptions,
  ): Core.APIPromise<ScheduleCreateResponse> {
    const { body, 'x-prefect-api-version': xPrefectAPIVersion } = params;
    return this._client.post(`/api/deployments/${id}/schedules`, {
      body: body,
      ...options,
      headers: {
        ...(xPrefectAPIVersion != null ? { 'x-prefect-api-version': xPrefectAPIVersion } : undefined),
        ...options?.headers,
      },
    });
  }

  /**
   * Update Deployment Schedule
   */
  update(
    id: string,
    scheduleId: string,
    params: ScheduleUpdateParams,
    options?: Core.RequestOptions,
  ): Core.APIPromise<void> {
    const { 'x-prefect-api-version': xPrefectAPIVersion, ...body } = params;
    return this._client.patch(`/api/deployments/${id}/schedules/${scheduleId}`, {
      body,
      ...options,
      headers: {
        Accept: '*/*',
        ...(xPrefectAPIVersion != null ? { 'x-prefect-api-version': xPrefectAPIVersion } : undefined),
        ...options?.headers,
      },
    });
  }

  /**
   * Read Deployment Schedules
   */
  list(
    id: string,
    params?: ScheduleListParams,
    options?: Core.RequestOptions,
  ): Core.APIPromise<ScheduleListResponse>;
  list(id: string, options?: Core.RequestOptions): Core.APIPromise<ScheduleListResponse>;
  list(
    id: string,
    params: ScheduleListParams | Core.RequestOptions = {},
    options?: Core.RequestOptions,
  ): Core.APIPromise<ScheduleListResponse> {
    if (isRequestOptions(params)) {
      return this.list(id, {}, params);
    }
    const { 'x-prefect-api-version': xPrefectAPIVersion } = params;
    return this._client.get(`/api/deployments/${id}/schedules`, {
      ...options,
      headers: {
        ...(xPrefectAPIVersion != null ? { 'x-prefect-api-version': xPrefectAPIVersion } : undefined),
        ...options?.headers,
      },
    });
  }

  /**
   * Delete Deployment Schedule
   */
  delete(
    id: string,
    scheduleId: string,
    params?: ScheduleDeleteParams,
    options?: Core.RequestOptions,
  ): Core.APIPromise<void>;
  delete(id: string, scheduleId: string, options?: Core.RequestOptions): Core.APIPromise<void>;
  delete(
    id: string,
    scheduleId: string,
    params: ScheduleDeleteParams | Core.RequestOptions = {},
    options?: Core.RequestOptions,
  ): Core.APIPromise<void> {
    if (isRequestOptions(params)) {
      return this.delete(id, scheduleId, {}, params);
    }
    const { 'x-prefect-api-version': xPrefectAPIVersion } = params;
    return this._client.delete(`/api/deployments/${id}/schedules/${scheduleId}`, {
      ...options,
      headers: {
        Accept: '*/*',
        ...(xPrefectAPIVersion != null ? { 'x-prefect-api-version': xPrefectAPIVersion } : undefined),
        ...options?.headers,
      },
    });
  }

  /**
   * Schedule runs for a deployment. For backfills, provide start/end times in the
   * past.
   *
   * This function will generate the minimum number of runs that satisfy the min and
   * max times, and the min and max counts. Specifically, the following order will be
   * respected.
   *
   *     - Runs will be generated starting on or after the `start_time`
   *     - No more than `max_runs` runs will be generated
   *     - No runs will be generated after `end_time` is reached
   *     - At least `min_runs` runs will be generated
   *     - Runs will be generated until at least `start_time + min_time` is reached
   */
  scheduleRuns(
    id: string,
    params?: ScheduleScheduleRunsParams,
    options?: Core.RequestOptions,
  ): Core.APIPromise<unknown>;
  scheduleRuns(id: string, options?: Core.RequestOptions): Core.APIPromise<unknown>;
  scheduleRuns(
    id: string,
    params: ScheduleScheduleRunsParams | Core.RequestOptions = {},
    options?: Core.RequestOptions,
  ): Core.APIPromise<unknown> {
    if (isRequestOptions(params)) {
      return this.scheduleRuns(id, {}, params);
    }
    const { 'x-prefect-api-version': xPrefectAPIVersion, ...body } = params;
    return this._client.post(`/api/deployments/${id}/schedule`, {
      body,
      ...options,
      headers: {
        ...(xPrefectAPIVersion != null ? { 'x-prefect-api-version': xPrefectAPIVersion } : undefined),
        ...options?.headers,
      },
    });
  }
}

export type ScheduleCreateResponse = Array<DeploymentsAPI.DeploymentSchedule>;

export type ScheduleListResponse = Array<DeploymentsAPI.DeploymentSchedule>;

export type ScheduleScheduleRunsResponse = unknown;

export interface ScheduleCreateParams {
  /**
   * Body param: The schedules to create
   */
  body: Array<ScheduleCreateParams.Body>;

  /**
   * Header param:
   */
  'x-prefect-api-version'?: string;
}

export namespace ScheduleCreateParams {
  export interface Body {
    /**
     * The schedule for the deployment.
     */
    schedule: Body.IntervalSchedule | Body.CronSchedule | Body.RRuleSchedule;

    /**
     * Whether or not the schedule is active.
     */
    active?: boolean;

    /**
     * Whether or not a worker should catch up on Late runs for the schedule.
     */
    catchup?: boolean;

    /**
     * The maximum number of active runs for the schedule.
     */
    max_active_runs?: number | null;

    /**
     * The maximum number of scheduled runs for the schedule.
     */
    max_scheduled_runs?: number | null;
  }

  export namespace Body {
    /**
     * A schedule formed by adding `interval` increments to an `anchor_date`. If no
     * `anchor_date` is supplied, the current UTC time is used. If a timezone-naive
     * datetime is provided for `anchor_date`, it is assumed to be in the schedule's
     * timezone (or UTC). Even if supplied with an IANA timezone, anchor dates are
     * always stored as UTC offsets, so a `timezone` can be provided to determine
     * localization behaviors like DST boundary handling. If none is provided it will
     * be inferred from the anchor date.
     *
     * NOTE: If the `IntervalSchedule` `anchor_date` or `timezone` is provided in a
     * DST-observing timezone, then the schedule will adjust itself appropriately.
     * Intervals greater than 24 hours will follow DST conventions, while intervals of
     * less than 24 hours will follow UTC intervals. For example, an hourly schedule
     * will fire every UTC hour, even across DST boundaries. When clocks are set back,
     * this will result in two runs that _appear_ to both be scheduled for 1am local
     * time, even though they are an hour apart in UTC time. For longer intervals, like
     * a daily schedule, the interval schedule will adjust for DST boundaries so that
     * the clock-hour remains constant. This means that a daily schedule that always
     * fires at 9am will observe DST and continue to fire at 9am in the local time
     * zone.
     *
     * Args: interval (datetime.timedelta): an interval to schedule on. anchor_date
     * (DateTime, optional): an anchor date to schedule increments against; if not
     * provided, the current timestamp will be used. timezone (str, optional): a valid
     * timezone string.
     */
    export interface IntervalSchedule {
      interval: number;

      anchor_date?: string;

      timezone?: string | null;
    }

    /**
     * Cron schedule
     *
     * NOTE: If the timezone is a DST-observing one, then the schedule will adjust
     * itself appropriately. Cron's rules for DST are based on schedule times, not
     * intervals. This means that an hourly cron schedule will fire on every new
     * schedule hour, not every elapsed hour; for example, when clocks are set back
     * this will result in a two-hour pause as the schedule will fire _the first time_
     * 1am is reached and _the first time_ 2am is reached, 120 minutes later. Longer
     * schedules, such as one that fires at 9am every morning, will automatically
     * adjust for DST.
     *
     * Args: cron (str): a valid cron string timezone (str): a valid timezone string in
     * IANA tzdata format (for example, America/New_York). day_or (bool, optional):
     * Control how croniter handles `day` and `day_of_week` entries. Defaults to True,
     * matching cron which connects those values using OR. If the switch is set to
     * False, the values are connected using AND. This behaves like fcron and enables
     * you to e.g. define a job that executes each 2nd friday of a month by setting the
     * days of month and the weekday.
     */
    export interface CronSchedule {
      cron: string;

      /**
       * Control croniter behavior for handling day and day_of_week entries.
       */
      day_or?: boolean;

      timezone?: string | null;
    }

    /**
     * RRule schedule, based on the iCalendar standard
     * ([RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545)) as implemented in
     * `dateutils.rrule`.
     *
     * RRules are appropriate for any kind of calendar-date manipulation, including
     * irregular intervals, repetition, exclusions, week day or day-of-month
     * adjustments, and more.
     *
     * Note that as a calendar-oriented standard, `RRuleSchedules` are sensitive to to
     * the initial timezone provided. A 9am daily schedule with a daylight saving
     * time-aware start date will maintain a local 9am time through DST boundaries; a
     * 9am daily schedule with a UTC start date will maintain a 9am UTC time.
     *
     * Args: rrule (str): a valid RRule string timezone (str, optional): a valid
     * timezone string
     */
    export interface RRuleSchedule {
      rrule: string;

      timezone?: string | null;
    }
  }
}

export interface ScheduleUpdateParams {
  /**
   * Body param: Whether or not the schedule is active.
   */
  active?: boolean | null;

  /**
   * Body param: Whether or not a worker should catch up on Late runs for the
   * schedule.
   */
  catchup?: boolean | null;

  /**
   * Body param: The maximum number of active runs for the schedule.
   */
  max_active_runs?: number | null;

  /**
   * Body param: The maximum number of scheduled runs for the schedule.
   */
  max_scheduled_runs?: number | null;

  /**
   * Body param: The schedule for the deployment.
   */
  schedule?:
    | ScheduleUpdateParams.IntervalSchedule
    | ScheduleUpdateParams.CronSchedule
    | ScheduleUpdateParams.RRuleSchedule
    | null;

  /**
   * Header param:
   */
  'x-prefect-api-version'?: string;
}

export namespace ScheduleUpdateParams {
  /**
   * A schedule formed by adding `interval` increments to an `anchor_date`. If no
   * `anchor_date` is supplied, the current UTC time is used. If a timezone-naive
   * datetime is provided for `anchor_date`, it is assumed to be in the schedule's
   * timezone (or UTC). Even if supplied with an IANA timezone, anchor dates are
   * always stored as UTC offsets, so a `timezone` can be provided to determine
   * localization behaviors like DST boundary handling. If none is provided it will
   * be inferred from the anchor date.
   *
   * NOTE: If the `IntervalSchedule` `anchor_date` or `timezone` is provided in a
   * DST-observing timezone, then the schedule will adjust itself appropriately.
   * Intervals greater than 24 hours will follow DST conventions, while intervals of
   * less than 24 hours will follow UTC intervals. For example, an hourly schedule
   * will fire every UTC hour, even across DST boundaries. When clocks are set back,
   * this will result in two runs that _appear_ to both be scheduled for 1am local
   * time, even though they are an hour apart in UTC time. For longer intervals, like
   * a daily schedule, the interval schedule will adjust for DST boundaries so that
   * the clock-hour remains constant. This means that a daily schedule that always
   * fires at 9am will observe DST and continue to fire at 9am in the local time
   * zone.
   *
   * Args: interval (datetime.timedelta): an interval to schedule on. anchor_date
   * (DateTime, optional): an anchor date to schedule increments against; if not
   * provided, the current timestamp will be used. timezone (str, optional): a valid
   * timezone string.
   */
  export interface IntervalSchedule {
    interval: number;

    anchor_date?: string;

    timezone?: string | null;
  }

  /**
   * Cron schedule
   *
   * NOTE: If the timezone is a DST-observing one, then the schedule will adjust
   * itself appropriately. Cron's rules for DST are based on schedule times, not
   * intervals. This means that an hourly cron schedule will fire on every new
   * schedule hour, not every elapsed hour; for example, when clocks are set back
   * this will result in a two-hour pause as the schedule will fire _the first time_
   * 1am is reached and _the first time_ 2am is reached, 120 minutes later. Longer
   * schedules, such as one that fires at 9am every morning, will automatically
   * adjust for DST.
   *
   * Args: cron (str): a valid cron string timezone (str): a valid timezone string in
   * IANA tzdata format (for example, America/New_York). day_or (bool, optional):
   * Control how croniter handles `day` and `day_of_week` entries. Defaults to True,
   * matching cron which connects those values using OR. If the switch is set to
   * False, the values are connected using AND. This behaves like fcron and enables
   * you to e.g. define a job that executes each 2nd friday of a month by setting the
   * days of month and the weekday.
   */
  export interface CronSchedule {
    cron: string;

    /**
     * Control croniter behavior for handling day and day_of_week entries.
     */
    day_or?: boolean;

    timezone?: string | null;
  }

  /**
   * RRule schedule, based on the iCalendar standard
   * ([RFC 5545](https://datatracker.ietf.org/doc/html/rfc5545)) as implemented in
   * `dateutils.rrule`.
   *
   * RRules are appropriate for any kind of calendar-date manipulation, including
   * irregular intervals, repetition, exclusions, week day or day-of-month
   * adjustments, and more.
   *
   * Note that as a calendar-oriented standard, `RRuleSchedules` are sensitive to to
   * the initial timezone provided. A 9am daily schedule with a daylight saving
   * time-aware start date will maintain a local 9am time through DST boundaries; a
   * 9am daily schedule with a UTC start date will maintain a 9am UTC time.
   *
   * Args: rrule (str): a valid RRule string timezone (str, optional): a valid
   * timezone string
   */
  export interface RRuleSchedule {
    rrule: string;

    timezone?: string | null;
  }
}

export interface ScheduleListParams {
  'x-prefect-api-version'?: string;
}

export interface ScheduleDeleteParams {
  'x-prefect-api-version'?: string;
}

export interface ScheduleScheduleRunsParams {
  /**
   * Body param: The latest date to schedule
   */
  end_time?: string;

  /**
   * Body param: The maximum number of runs to schedule
   */
  max_runs?: number;

  /**
   * Body param: The minimum number of runs to schedule
   */
  min_runs?: number;

  /**
   * Body param: Runs will be scheduled until at least this long after the
   * `start_time`
   */
  min_time?: number;

  /**
   * Body param: The earliest date to schedule
   */
  start_time?: string;

  /**
   * Header param:
   */
  'x-prefect-api-version'?: string;
}

export namespace Schedules {
  export import ScheduleCreateResponse = SchedulesAPI.ScheduleCreateResponse;
  export import ScheduleListResponse = SchedulesAPI.ScheduleListResponse;
  export import ScheduleScheduleRunsResponse = SchedulesAPI.ScheduleScheduleRunsResponse;
  export import ScheduleCreateParams = SchedulesAPI.ScheduleCreateParams;
  export import ScheduleUpdateParams = SchedulesAPI.ScheduleUpdateParams;
  export import ScheduleListParams = SchedulesAPI.ScheduleListParams;
  export import ScheduleDeleteParams = SchedulesAPI.ScheduleDeleteParams;
  export import ScheduleScheduleRunsParams = SchedulesAPI.ScheduleScheduleRunsParams;
}