Description
Add airflowctl tasks logs — fetch a task instance's logs for a given try number, mirroring the existing Core REST API endpoint GET /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} (/api/v2).
This isn't a "migration" like the other tasks commands — the legacy airflow CLI never had a tasks logs subcommand to begin with (log access has always been webserver-UI/REST-only), so there's nothing to deprecate/mark. It's a net-new capability for airflowctl, matching what's described in #68402 as "another side of AIP-94."
The umbrella tracking issue #68402 lists tasks state / states-for-dag-run / clear / list / failed-deps but not logs; checked as of 2026-07 and found no existing issue or PR proposing this.
Use case/motivation
Operating Airflow without direct DB/webserver access (e.g. via kubectl exec or a remote API client) needs the full task-troubleshooting loop: list failed tasks → check state → pull logs to diagnose why it failed → clear for retry once the root cause is understood (or a transient failure is confirmed). Every other step in that loop already has (or has an in-flight PR for) an airflowctl command; log retrieval is the one gap still forcing a fallback to the webserver UI or a hand-rolled REST client.
Suggested shape, matching the CLI conventions used by the in-flight tasks state/tasks clear PRs:
airflowctl tasks logs --dag-id <DAG> --dag-run-id <RUN> --task-id <TASK> [--map-index <N>] [--try-number <N>]
--try-number defaults to the latest attempt if omitted (matches webserver UI behavior).- Should only call the primary
logs/{try_number} endpoint. The separate externalLogUrl endpoint (relevant only for Elasticsearch/OpenSearch-backed deployments) can be left for a follow-up, to keep scope narrow.
Related issues
Are you willing to submit a PR?
Code of Conduct
Description
Add
airflowctl tasks logs— fetch a task instance's logs for a given try number, mirroring the existing Core REST API endpointGET /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}(/api/v2).This isn't a "migration" like the other
taskscommands — the legacyairflowCLI never had atasks logssubcommand to begin with (log access has always been webserver-UI/REST-only), so there's nothing to deprecate/mark. It's a net-new capability for airflowctl, matching what's described in #68402 as "another side of AIP-94."The umbrella tracking issue #68402 lists
tasks state/states-for-dag-run/clear/list/failed-depsbut notlogs; checked as of 2026-07 and found no existing issue or PR proposing this.Use case/motivation
Operating Airflow without direct DB/webserver access (e.g. via
kubectl execor a remote API client) needs the full task-troubleshooting loop: list failed tasks → check state → pull logs to diagnose why it failed → clear for retry once the root cause is understood (or a transient failure is confirmed). Every other step in that loop already has (or has an in-flight PR for) an airflowctl command; log retrieval is the one gap still forcing a fallback to the webserver UI or a hand-rolled REST client.Suggested shape, matching the CLI conventions used by the in-flight
tasks state/tasks clearPRs:airflowctl tasks logs --dag-id <DAG> --dag-run-id <RUN> --task-id <TASK> [--map-index <N>] [--try-number <N>]--try-numberdefaults to the latest attempt if omitted (matches webserver UI behavior).logs/{try_number}endpoint. The separateexternalLogUrlendpoint (relevant only for Elasticsearch/OpenSearch-backed deployments) can be left for a follow-up, to keep scope narrow.Related issues
logsisn't on the trackedtaskschecklist)tasks state) / [AIP-94] airflowctl tasks: add states-for-dag-run command #66175 (tasks states-for-dag-run) / [AIP-94] airflowctl tasks: add clear command #66176 (tasks clear)Are you willing to submit a PR?
Code of Conduct