Add airflowctl tasks logs command for retrieving task instance logs by BobSong-dev · Pull Request #71763 · apache/airflow

BobSong-dev · 2026-08-18T10:23:27Z

Summary
Add the airflowctl tasks logs command to fetch a task instance's logs for a given try through the existing REST endpoint.

Changes

Add TaskInstancesOperations.logs() calling GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}.
Register the tasks logs command: airflowctl tasks logs DAG_ID DAG_RUN_ID TASK_ID [--map-index N] [--try-number N]; --try-number defaults to the latest attempt, matching the webserver UI.
Keep required parameters positional per the airflowctl parameter style consensus (airflowctl: make required CLI params positional, keep optional as --flag #66768); the issue's suggested --dag-id/--dag-run-id/--task-id flag form was dropped to comply with that convention.
Limit scope to the primary logs endpoint; externalLogUrl handling is left for a follow-up.

Testing
Added unit tests covering the command: default latest attempt, explicit try number and map index, structured and plain-text log output, 404 handling, and non-404 error propagation. All 35 tests in test_task_command.py pass. Added tasks logs lines to the integration test command list. ruff format and ruff check pass on all changed files.

closes: #69947

Was generative AI tooling used to co-author this PR?

Yes — DeepSeek V4 Pro

Generated-by: DeepSeek V4 Pro following the guidelines，I also conducted local testing, and no issues were found.

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Without direct DB or webserver access, operators can list failed task instances, check their state and clear them for retry, but retrieving the logs needed to diagnose the failure still forced a fallback to the webserver UI or a hand-rolled REST client. This closes that gap by fetching task instance logs for a given try through the existing /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} endpoint, defaulting to the latest attempt.

boring-cyborg · 2026-08-18T10:23:31Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

BobSong-dev · 2026-08-18T10:23:27Z

Summary
Add the airflowctl tasks logs command to fetch a task instance's logs for a given try through the existing REST endpoint.

Changes

Add TaskInstancesOperations.logs() calling GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}.
Register the tasks logs command: airflowctl tasks logs DAG_ID DAG_RUN_ID TASK_ID [--map-index N] [--try-number N]; --try-number defaults to the latest attempt, matching the webserver UI.
Keep required parameters positional per the airflowctl parameter style consensus (airflowctl: make required CLI params positional, keep optional as --flag #66768); the issue's suggested --dag-id/--dag-run-id/--task-id flag form was dropped to comply with that convention.
Limit scope to the primary logs endpoint; externalLogUrl handling is left for a follow-up.

Testing
Added unit tests covering the command: default latest attempt, explicit try number and map index, structured and plain-text log output, 404 handling, and non-404 error propagation. All 35 tests in test_task_command.py pass. Added tasks logs lines to the integration test command list. ruff format and ruff check pass on all changed files.

closes: #69947

Was generative AI tooling used to co-author this PR?

Yes — DeepSeek V4 Pro

Generated-by: DeepSeek V4 Pro following the guidelines，I also conducted local testing, and no issues were found.

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Without direct DB or webserver access, operators can list failed task instances, check their state and clear them for retry, but retrieving the logs needed to diagnose the failure still forced a fallback to the webserver UI or a hand-rolled REST client. This closes that gap by fetching task instance logs for a given try through the existing /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} endpoint, defaulting to the latest attempt.

boring-cyborg · 2026-08-18T10:23:31Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

BobSong-dev · 2026-08-18T10:23:27Z

Summary
Add the airflowctl tasks logs command to fetch a task instance's logs for a given try through the existing REST endpoint.

Changes

Add TaskInstancesOperations.logs() calling GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}.
Register the tasks logs command: airflowctl tasks logs DAG_ID DAG_RUN_ID TASK_ID [--map-index N] [--try-number N]; --try-number defaults to the latest attempt, matching the webserver UI.
Keep required parameters positional per the airflowctl parameter style consensus (airflowctl: make required CLI params positional, keep optional as --flag #66768); the issue's suggested --dag-id/--dag-run-id/--task-id flag form was dropped to comply with that convention.
Limit scope to the primary logs endpoint; externalLogUrl handling is left for a follow-up.

Testing
Added unit tests covering the command: default latest attempt, explicit try number and map index, structured and plain-text log output, 404 handling, and non-404 error propagation. All 35 tests in test_task_command.py pass. Added tasks logs lines to the integration test command list. ruff format and ruff check pass on all changed files.

closes: #69947

Was generative AI tooling used to co-author this PR?

Yes — DeepSeek V4 Pro

Generated-by: DeepSeek V4 Pro following the guidelines，I also conducted local testing, and no issues were found.

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Without direct DB or webserver access, operators can list failed task instances, check their state and clear them for retry, but retrieving the logs needed to diagnose the failure still forced a fallback to the webserver UI or a hand-rolled REST client. This closes that gap by fetching task instance logs for a given try through the existing /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} endpoint, defaulting to the latest attempt.

boring-cyborg · 2026-08-18T10:23:31Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

BobSong-dev · 2026-08-18T10:23:27Z

Summary
Add the airflowctl tasks logs command to fetch a task instance's logs for a given try through the existing REST endpoint.

Changes

Add TaskInstancesOperations.logs() calling GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}.
Register the tasks logs command: airflowctl tasks logs DAG_ID DAG_RUN_ID TASK_ID [--map-index N] [--try-number N]; --try-number defaults to the latest attempt, matching the webserver UI.
Keep required parameters positional per the airflowctl parameter style consensus (airflowctl: make required CLI params positional, keep optional as --flag #66768); the issue's suggested --dag-id/--dag-run-id/--task-id flag form was dropped to comply with that convention.
Limit scope to the primary logs endpoint; externalLogUrl handling is left for a follow-up.

Testing
Added unit tests covering the command: default latest attempt, explicit try number and map index, structured and plain-text log output, 404 handling, and non-404 error propagation. All 35 tests in test_task_command.py pass. Added tasks logs lines to the integration test command list. ruff format and ruff check pass on all changed files.

closes: #69947

Was generative AI tooling used to co-author this PR?

Yes — DeepSeek V4 Pro

Generated-by: DeepSeek V4 Pro following the guidelines，I also conducted local testing, and no issues were found.

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Without direct DB or webserver access, operators can list failed task instances, check their state and clear them for retry, but retrieving the logs needed to diagnose the failure still forced a fallback to the webserver UI or a hand-rolled REST client. This closes that gap by fetching task instance logs for a given try through the existing /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} endpoint, defaulting to the latest attempt.

boring-cyborg · 2026-08-18T10:23:31Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

BobSong-dev · 2026-08-18T10:23:27Z

Summary
Add the airflowctl tasks logs command to fetch a task instance's logs for a given try through the existing REST endpoint.

Changes

Add TaskInstancesOperations.logs() calling GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}.
Register the tasks logs command: airflowctl tasks logs DAG_ID DAG_RUN_ID TASK_ID [--map-index N] [--try-number N]; --try-number defaults to the latest attempt, matching the webserver UI.
Keep required parameters positional per the airflowctl parameter style consensus (airflowctl: make required CLI params positional, keep optional as --flag #66768); the issue's suggested --dag-id/--dag-run-id/--task-id flag form was dropped to comply with that convention.
Limit scope to the primary logs endpoint; externalLogUrl handling is left for a follow-up.

Testing
Added unit tests covering the command: default latest attempt, explicit try number and map index, structured and plain-text log output, 404 handling, and non-404 error propagation. All 35 tests in test_task_command.py pass. Added tasks logs lines to the integration test command list. ruff format and ruff check pass on all changed files.

closes: #69947

Was generative AI tooling used to co-author this PR?

Yes — DeepSeek V4 Pro

Generated-by: DeepSeek V4 Pro following the guidelines，I also conducted local testing, and no issues were found.

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Without direct DB or webserver access, operators can list failed task instances, check their state and clear them for retry, but retrieving the logs needed to diagnose the failure still forced a fallback to the webserver UI or a hand-rolled REST client. This closes that gap by fetching task instance logs for a given try through the existing /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} endpoint, defaulting to the latest attempt.

boring-cyborg · 2026-08-18T10:23:31Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

BobSong-dev · 2026-08-18T10:23:27Z

Summary
Add the airflowctl tasks logs command to fetch a task instance's logs for a given try through the existing REST endpoint.

Changes

Add TaskInstancesOperations.logs() calling GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}.
Register the tasks logs command: airflowctl tasks logs DAG_ID DAG_RUN_ID TASK_ID [--map-index N] [--try-number N]; --try-number defaults to the latest attempt, matching the webserver UI.
Keep required parameters positional per the airflowctl parameter style consensus (airflowctl: make required CLI params positional, keep optional as --flag #66768); the issue's suggested --dag-id/--dag-run-id/--task-id flag form was dropped to comply with that convention.
Limit scope to the primary logs endpoint; externalLogUrl handling is left for a follow-up.

Testing
Added unit tests covering the command: default latest attempt, explicit try number and map index, structured and plain-text log output, 404 handling, and non-404 error propagation. All 35 tests in test_task_command.py pass. Added tasks logs lines to the integration test command list. ruff format and ruff check pass on all changed files.

closes: #69947

Was generative AI tooling used to co-author this PR?

Yes — DeepSeek V4 Pro

Generated-by: DeepSeek V4 Pro following the guidelines，I also conducted local testing, and no issues were found.

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Without direct DB or webserver access, operators can list failed task instances, check their state and clear them for retry, but retrieving the logs needed to diagnose the failure still forced a fallback to the webserver UI or a hand-rolled REST client. This closes that gap by fetching task instance logs for a given try through the existing /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} endpoint, defaulting to the latest attempt.

boring-cyborg · 2026-08-18T10:23:31Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

BobSong-dev · 2026-08-18T10:23:27Z

Summary
Add the airflowctl tasks logs command to fetch a task instance's logs for a given try through the existing REST endpoint.

Changes

Add TaskInstancesOperations.logs() calling GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}.
Register the tasks logs command: airflowctl tasks logs DAG_ID DAG_RUN_ID TASK_ID [--map-index N] [--try-number N]; --try-number defaults to the latest attempt, matching the webserver UI.
Keep required parameters positional per the airflowctl parameter style consensus (airflowctl: make required CLI params positional, keep optional as --flag #66768); the issue's suggested --dag-id/--dag-run-id/--task-id flag form was dropped to comply with that convention.
Limit scope to the primary logs endpoint; externalLogUrl handling is left for a follow-up.

Testing
Added unit tests covering the command: default latest attempt, explicit try number and map index, structured and plain-text log output, 404 handling, and non-404 error propagation. All 35 tests in test_task_command.py pass. Added tasks logs lines to the integration test command list. ruff format and ruff check pass on all changed files.

closes: #69947

Was generative AI tooling used to co-author this PR?

Yes — DeepSeek V4 Pro

Generated-by: DeepSeek V4 Pro following the guidelines，I also conducted local testing, and no issues were found.

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Without direct DB or webserver access, operators can list failed task instances, check their state and clear them for retry, but retrieving the logs needed to diagnose the failure still forced a fallback to the webserver UI or a hand-rolled REST client. This closes that gap by fetching task instance logs for a given try through the existing /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} endpoint, defaulting to the latest attempt.

boring-cyborg · 2026-08-18T10:23:31Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack

BobSong-dev · 2026-08-18T10:23:27Z

Summary
Add the airflowctl tasks logs command to fetch a task instance's logs for a given try through the existing REST endpoint.

Changes

Add TaskInstancesOperations.logs() calling GET /api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}.
Register the tasks logs command: airflowctl tasks logs DAG_ID DAG_RUN_ID TASK_ID [--map-index N] [--try-number N]; --try-number defaults to the latest attempt, matching the webserver UI.
Keep required parameters positional per the airflowctl parameter style consensus (airflowctl: make required CLI params positional, keep optional as --flag #66768); the issue's suggested --dag-id/--dag-run-id/--task-id flag form was dropped to comply with that convention.
Limit scope to the primary logs endpoint; externalLogUrl handling is left for a follow-up.

Testing
Added unit tests covering the command: default latest attempt, explicit try number and map index, structured and plain-text log output, 404 handling, and non-404 error propagation. All 35 tests in test_task_command.py pass. Added tasks logs lines to the integration test command list. ruff format and ruff check pass on all changed files.

closes: #69947

Was generative AI tooling used to co-author this PR?

Yes — DeepSeek V4 Pro

Generated-by: DeepSeek V4 Pro following the guidelines，I also conducted local testing, and no issues were found.

Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
When adding dependency, check compliance with the ASF 3rd Party License Policy.
For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

Without direct DB or webserver access, operators can list failed task instances, check their state and clear them for retry, but retrieving the logs needed to diagnose the failure still forced a fallback to the webserver UI or a hand-rolled REST client. This closes that gap by fetching task instance logs for a given try through the existing /dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number} endpoint, defaulting to the latest attempt.

boring-cyborg · 2026-08-18T10:23:31Z

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
Be sure to read the Airflow Coding style.
Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
Apache Airflow is a community-driven project and together we are making it better 🚀.
In case of doubts contact the developers at:
Mailing List: dev@airflow.apache.org
Slack: https://s.apache.org/airflow-slack