Eason09053360 commented on code in PR #72109:
URL: https://github.com/apache/airflow/pull/72109#discussion_r3869093971
##########
airflow-core/src/airflow/cli/commands/dag_command.py:
##########
Review Comment:
Good catch — confirmed, and it's even worse than the example: regexp_match
is unanchored on Postgres (~) and MySQL (REGEXP), so foo.bar also matches
things like `staging_fooXbar_v2`, not just `fooXbar`.
I went with normalising the flag at its source instead of guarding the query:
`if dag:`
`args.dag_id = dag.dag_id`
`args.treat_dag_id_as_regex = False`
The reason is that `args.treat_dag_id_as_regex` has two readers, and the
suggested change only covers the first one. With it applied, the query is
correct but the confirmation branch below still fires — I verified this,
ask_yesno gets called with `"You are about to pause 1
DAGs:\ndag.cli_regex_target\n\nAre you sure? [y/n]"`, which would block on
stdin in real use. Fixing the value covers both readers, and any future one.
Added the test: `dag.cli_regex_target and dagXcli_regex_target` both in the
DB, invoked through the Dag-scoped parser with --treat-dag-id-as-regex. It
asserts the sibling is untouched and that ask_yesno is never called. Without
the fix both Dags get paused.
Also renamed the `dag` loop variable in the comprehension below to
`dag_model`, since it now shadows the new parameter.
--
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]
