-
Notifications
You must be signed in to change notification settings - Fork 15.9k
Remove dagReports API endpoint
#56609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The `/api/v2/dagReports` endpoint loaded user DAG files directly in the API server process via DagBag, violating Airflow's core architectural principle that the API server must never execute user code. The endpoint was not used by the UI and had no known consumers. Users needing DAG loading reports should use the `airflow dags report` CLI command instead, which runs in an isolated process designed to safely execute user code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch! Thanks for the fix.
I just double checked the Core API and Execution API, only dagReports API is using DagBag, the rest of the APIs are using DBDagBag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
Backport failed to create: v3-1-test. View the failure log Run details
You can attempt to backport this manually by running: cherry_picker 828aaa0 v3-1-testThis should apply the commit to the v3-1-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continue |
The `/api/v2/dagReports` endpoint loaded user DAG files directly in the API server process via DagBag, violating Airflow's core architectural principle that the API server must never execute user code. The endpoint was not used by the UI and had no known consumers. Users needing DAG loading reports should use the `airflow dags report` CLI command instead, which runs in an isolated process designed to safely execute user code. (cherry picked from commit 828aaa0) Co-authored-by: Kaxil Naik <[email protected]>
|
Backport in #56621 |
The `/api/v2/dagReports` endpoint loaded user DAG files directly in the API server process via DagBag, violating Airflow's core architectural principle that the API server must never execute user code. The endpoint was not used by the UI and had no known consumers. Users needing DAG loading reports should use the `airflow dags report` CLI command instead, which runs in an isolated process designed to safely execute user code. (cherry picked from commit 828aaa0) Co-authored-by: Kaxil Naik <[email protected]>
The `/api/v2/dagReports` endpoint loaded user DAG files directly in the API server process via DagBag, violating Airflow's core architectural principle that the API server must never execute user code. The endpoint was not used by the UI and had no known consumers. Users needing DAG loading reports should use the `airflow dags report` CLI command instead, which runs in an isolated process designed to safely execute user code.
The `/api/v2/dagReports` endpoint loaded user DAG files directly in the API server process via DagBag, violating Airflow's core architectural principle that the API server must never execute user code. The endpoint was not used by the UI and had no known consumers. Users needing DAG loading reports should use the `airflow dags report` CLI command instead, which runs in an isolated process designed to safely execute user code.
The `/api/v2/dagReports` endpoint loaded user DAG files directly in the API server process via DagBag, violating Airflow's core architectural principle that the API server must never execute user code. The endpoint was not used by the UI and had no known consumers. Users needing DAG loading reports should use the `airflow dags report` CLI command instead, which runs in an isolated process designed to safely execute user code.
The `/api/v2/dagReports` endpoint loaded user DAG files directly in the API server process via DagBag, violating Airflow's core architectural principle that the API server must never execute user code. The endpoint was not used by the UI and had no known consumers. Users needing DAG loading reports should use the `airflow dags report` CLI command instead, which runs in an isolated process designed to safely execute user code.
The
/api/v2/dagReportsendpoint loaded user DAG files directly in the API server process via DagBag, violating Airflow's core architectural principle that the API server must never execute user code.The endpoint was not used by the UI and had no known consumers. Users needing DAG loading reports should use the
airflow dags reportCLI command instead, which runs in an isolated process designed to safely execute user code.^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.