guan404ming commented on code in PR #62374:
URL: https://github.com/apache/airflow/pull/62374#discussion_r2844988234
##########
airflow-core/src/airflow/ui/openapi-gen/requests/services.gen.ts:
##########
@@ -3923,17 +3923,25 @@ export class DeadlinesService {
* Get all deadlines for a specific DAG run.
* @param data The data for the request.
* @param data.dagId
- * @param data.runId
- * @returns DeadlineResponse Successful Response
+ * @param data.dagRunId
+ * @param data.limit
+ * @param data.offset
+ * @param data.orderBy Attributes to order by, multi criteria sort is
supported. Prefix with `-` for descending order. Supported attributes: `id,
deadline_time, created_at, alert_name`
+ * @returns DealineCollectionResponse Successful Response
* @throws ApiError
*/
public static getDagRunDeadlines(data: GetDagRunDeadlinesData):
CancelablePromise<GetDagRunDeadlinesResponse> {
return __request(OpenAPI, {
method: 'GET',
- url: '/ui/deadlines/{dag_id}/{run_id}',
+ url: '/ui/dags/{dag_id}/dagRuns/{dag_run_id}/deadlines',
Review Comment:
Thanks for asking, this is a great question. My two cents: this version is
mainly better in terms of semantic correctness and consistency with our
existing REST patterns.
In this case, deadlines are conceptually scoped under a specific dag run, so
expressing the path as `/dags/{dag_id}/dagRuns/{dag_run_id}/deadlines` makes
that parent–child relationship explicit. It also aligns with how other
resources are structured under dags and dagRuns, which makes the API more
predictable and easier to reason about. The previous path works functionally,
but it’s a bit less clear in terms of resource hierarchy and deviates from the
conventions we’ve been following.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
