kremogen commented on PR #65839:
URL: https://github.com/apache/airflow/pull/65839#issuecomment-4341828692
> That's fair, but I'm arguing about the 'new' endpoint.
>
> You can already do this today in your CI, the only constraint is that you
need an API call to retrieve the Dag (1 at a time), or Dags (a full page that
you can filter out by criteria), this will get you the required tokens, then
start your 'reparse' requests.
>
> Is there any specific use case not covered by this that would require this
extra endpoint?
Fair point - and I don't want to push back on that. My concern is that the
current flow leaks that implementation detail into the public API: a CI/CD
client that just deployed a code change knows the `dag_id` (that's what
developers commit), not `bundle_name` / `relative_fileloc`, and certainly not a
server-signed `file_token`. Forcing it to do `GET /dags/{dag_id}` purely to
extract a token that the server then decodes back to `(bundle_name,
relative_fileloc)` is a round-trip that exists only because we expose the
parser's internal addressing scheme.
The token also isn't a security boundary here - auth is
`requires_access_dag(method="PUT")` in both endpoints, so dropping the token
doesn't loosen anything.
To keep the file-oriented semantics honest rather than hidden, I'm happy to
reword the endpoint as "Request re-parsing of the file containing this DAG" and
explicitly note that other DAGs defined in the same file will be reparsed too.
Would that work for you?
--
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]
