Skip to content

Conversation

@kaxil
Copy link
Member

@kaxil kaxil commented Oct 14, 2025

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.


^ 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.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

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.
@boring-cyborg boring-cyborg bot added area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers. labels Oct 14, 2025
@kaxil kaxil added this to the Airflow 3.1.1 milestone Oct 14, 2025
Copy link
Member

@jason810496 jason810496 left a 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.

Copy link
Member

@pierrejeambrun pierrejeambrun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@pierrejeambrun pierrejeambrun added the backport-to-v3-1-test Mark PR with this label to backport to v3-1-test branch label Oct 14, 2025
Copy link
Member

@potiuk potiuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Copy link
Contributor

@amoghrajesh amoghrajesh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice

@jason810496 jason810496 merged commit 828aaa0 into apache:main Oct 14, 2025
114 checks passed
@github-actions
Copy link

Backport failed to create: v3-1-test. View the failure log Run details

Status Branch Result
v3-1-test Commit Link

You can attempt to backport this manually by running:

cherry_picker 828aaa0 v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

potiuk pushed a commit to potiuk/airflow that referenced this pull request Oct 14, 2025
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]>
@potiuk
Copy link
Member

potiuk commented Oct 14, 2025

Backport in #56621

potiuk added a commit that referenced this pull request Oct 14, 2025
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]>
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 15, 2025
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.
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 17, 2025
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.
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 19, 2025
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.
TyrellHaywood pushed a commit to TyrellHaywood/airflow that referenced this pull request Oct 22, 2025
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers. backport-to-v3-1-test Mark PR with this label to backport to v3-1-test branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants