Skip to content
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

AIP-84: Add UI batch recent dag runs endpoint #43204

Conversation

jason810496
Copy link
Contributor

closes: #42933
Same filter with public get_dags endpoint, but remove order_by params.

@boring-cyborg boring-cyborg bot added the area:UI Related to UI/UX. For Frontend Developers. label Oct 20, 2024
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.

Nice

airflow/api_fastapi/core_api/routes/ui/dags.py Outdated Show resolved Hide resolved
@jason810496 jason810496 force-pushed the feature/AIP-84/add-UI-batch-recent_dag_runs-endpoint branch from 0b552c7 to 5252d7a Compare October 21, 2024 15:25
@jason810496
Copy link
Contributor Author

Refactor:

Used DAGRunResponse, DAGCollectionResponse, and DAGResponse from the public serializers for the UI batch of recent runs. However, the subclasses that inherit from the public serializers should also inherit from OptionalModel, as most of the fields should be optional.

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.

I am not sure I understand the OptionalModel. Why do those DAGRuns and DAGs omit fields in the private response compare to the public one ?

I would assume that all of the public fields are also defined and here in the private endpoint therefore removing the need for that OptionalModel class. Did you encounter a specific issue ?

@jason810496
Copy link
Contributor Author

I think for this UI, the endpoint doesn't need to respond with so much information (compared with /last_dagruns in views.py). In /last_dagruns, it only needs dag_id, start_date, end_date, state, execution_date, data_interval_start, and data_interval_end.

Instead of marking the fields that aren't needed in this endpoint as optional in DAGRunResponse, I think inheriting from OptionalModel to mark the entire RecentDAGRunResponse would be clearer.

@Lee-W Lee-W added AIP-84 Modern Rest API area:API Airflow's REST/HTTP API labels Oct 22, 2024
@pierrejeambrun
Copy link
Member

pierrejeambrun commented Oct 22, 2024

I think we can just return the whole information and don't bother filtering things out. For the front-end it is easier because you only manipulate 1 type for the returned DAG, DagRun, etc... You do not have different representation depending on the endpoint (private/public), which makes things easier to work with (fill/cast etc..).

Note: Most likely not needed here, but if you want to return a subpart of a model, the pydantic documentation explains it well, you can jus use the response_model, with a minimal model having only the fields that you need. https://fastapi.tiangolo.com/tutorial/response-model/#response_model-parameter. We would most likely not use a custom all optional OptionalModel for that.

@jason810496 jason810496 force-pushed the feature/AIP-84/add-UI-batch-recent_dag_runs-endpoint branch from 5252d7a to 47c69b9 Compare October 23, 2024 06:28
@jason810496
Copy link
Contributor Author

Resolved:

Made this UI endpoint more consistent with the public endpoint by removing OptionalModel and using DAGRunResponse directly from the public endpoint instead.

@pierrejeambrun
Copy link
Member

@jason810496 Nice, I just added a small commit on top to make a few adjustment, let me know what you think, I believe we can merge then.

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.

NIce

@jason810496
Copy link
Contributor Author

Hi @pierrejeambrun, the changes look good to me, but I have another question:

When should I utilize a parameter class (the classes declared in common/parameters.py with to_orm and depends methods) instead of adding query parameters directly (like dag_runs_limit: int = 10 in this case)?

For example, in the Event Log endpoints, the query should leverage paginated_select, but the paginated_select function depends on a parameter class rather than query parameters. In this case, should I declare all filter classes in common/parameters.py, or would it be better to add a FilterParam with dynamic_depends, similar to SortParam, that could be used across all endpoints?

@pierrejeambrun
Copy link
Member

pierrejeambrun commented Oct 24, 2024

When should I utilize a parameter class (the classes declared in common/parameters.py with to_orm and depends methods) instead of adding query parameters directly (like dag_runs_limit: int = 10 in this case)?
For example, in the Event Log endpoints, the query should leverage paginated_select, but the paginated_select function depends on a parameter class rather than query parameters. In this case, should I declare all filter classes in common/parameters.py, or would it be better to add a FilterParam with dynamic_depends, similar to SortParam, that could be used across all endpoints?

The idea is if the parameter (query or path) is meant to be re-used in other endpoints and implement a common db operation (filtering, sorting, matching, anything), then it should go into parameters with our common parameters.

If like here it is a very specific one, in terms of parameters (a secondary limit index operating on nested ressources) in terms of naming "dag_runs_limit", and in terms of implementation (.where(recent_runs_subquery.c.rank <= dag_runs_limit) which is really specific to the subquery), then it's ok to leave it in the router and not bother creating a reusable 'parameters' out of if.

@pierrejeambrun pierrejeambrun force-pushed the feature/AIP-84/add-UI-batch-recent_dag_runs-endpoint branch from cf18fd3 to e20cd91 Compare October 24, 2024 15:38
@pierrejeambrun pierrejeambrun force-pushed the feature/AIP-84/add-UI-batch-recent_dag_runs-endpoint branch from e20cd91 to c58a7e7 Compare October 25, 2024 07:39
@pierrejeambrun pierrejeambrun merged commit 14abd33 into apache:main Oct 25, 2024
52 checks passed
ellisms pushed a commit to ellisms/airflow that referenced this pull request Nov 13, 2024
* AIP-84 | add UI batch recent dag runs endpoint

* AIP-84 | add UI batch recent dag runs

* refactor: use public serializer for ui batch recent runs

* fix: add trigger_by for dag run in public test_dag

* refactor: use DAGRunResponse from public endpoint

* Update code review

---------

Co-authored-by: pierrejeambrun <pierrejbrun@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AIP-84 Modern Rest API area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

AIP-84 Add UI batch recent_dag_runs endpoint
3 participants