airflow_pydantic.TaskArgs

pydantic model airflow_pydantic.TaskArgs

Bases: BaseModel

field owner: str | None = None

the owner of the task. Using a meaningful description (e.g. user/person/team/role name) to clarify ownership is recommended.

field email: list[str] | None = None

the ‘to’ email address(es) used in email alerts

field email_on_failure: bool | None = None

Indicates whether email alerts should be sent when a task failed

field email_on_retry: bool | None = None

Indicates whether email alerts should be sent when a task is retried

field retries: int | None = None

the number of retries that should be performed before failing the task

field retry_delay: timedelta | None = None

delay between retries

field retry_exponential_backoff: bool | None = None

allow progressively longer waits between retries by using exponential backoff algorithm on retry delay (delay will be converted into seconds)

field max_retry_delay: timedelta | None = None

maximum delay interval between retries

field start_date: Annotated[datetime | tuple[datetime, str], AfterValidator(func=_datetime_or_datetime_and_timezone)] | None = None

The start_date for the task, determines the execution_date for the first task instance. The best practice is to have the start_date rounded to your DAG’s schedule_interval. Daily jobs have their start_date some day at 00:00:00, hourly jobs have their start_date at 00:00 of a specific hour. Note that Airflow simply looks at the latest execution_date and adds the schedule_interval to determine the next execution_date. It is also very important to note that different tasks’ dependencies need to line up in time. If task A depends on task B and their start_date are offset in a way that their execution_date don’t line up, A’s dependencies will never be met. If you are looking to delay a task, for example running a daily task at 2AM, look into the TimeSensor and TimeDeltaSensor. We advise against using dynamic start_date and recommend using fixed ones. Read the FAQ entry about start_date for more information.

field end_date: Annotated[datetime | tuple[datetime, str], AfterValidator(func=_datetime_or_datetime_and_timezone)] | None = None

if specified, the scheduler won’t go beyond this date

field depends_on_past: bool | None = None

when set to true, task instances will run sequentially and only if the previous instance has succeeded or has been skipped. The task instance for the start_date is allowed to run.

field queue: str | None = None

which queue to target when running this job. Not all executors implement queue management, the CeleryExecutor does support targeting specific queues.

field pool: str | Pool | None = None

the slot pool this task should run in, slot pools are a way to limit concurrency for certain tasks

field pool_slots: int | None = None

the number of pool slots this task should use (>= 1) Values less than 1 are not allowed

field execution_timeout: timedelta | None = None

max time allowed for the execution of this task instance, if it goes beyond it will raise and fail.

field trigger_rule: TriggerRule | None = None

defines the rule by which dependencies are applied for the task to get triggered.

field max_active_tis_per_dag: int | None = None

When set, a task will be able to limit the concurrent runs across execution_dates.

field max_active_tis_per_dagrun: int | None = None

When set, a task will be able to limit the concurrent task instances per DAG run.

field do_xcom_push: bool | None = None

if True, an XCom is pushed containing the Operator’s result

field multiple_outputs: bool | None = None

if True and do_xcom_push is True, pushes multiple XComs, one for each key in the returned dictionary result. If False and do_xcom_push is True, pushes a single XCom.

field doc: str | None = None

Add documentation or notes to your Task objects that is visible in Task Instance details View in the Webserver. This is a generic field that can be used for any format, but it is recommended to use specific fields for structured formats like Markdown, RST, JSON, or YAML.

field doc_md: str | None = None

Add documentation in Markdown format or notes to your Task objects that is visible in Task Instance details View in the Webserver.

field doc_rst: str | None = None

Add documentation in RST format or notes to your Task objects that is visible in Task Instance details View in the Webserver.

field doc_json: str | None = None

Add documentation in JSON format or notes to your Task objects that is visible in Task Instance details View in the Webserver.

field doc_yaml: str | None = None

Add documentation in YAML format or notes to your Task objects that is visible in Task Instance details View in the Webserver.

field task_display_name: str | None = None

The display name of the task which appears on the UI.