Skip to content

Remove no-op overrides and deduplicate Dag run lookup in airflowctl - #70898

Closed
rjgoyln wants to merge 1 commit into
apache:mainfrom
rjgoyln:cleanup/airflowctl-dead-code-and-dag-run-lookup
Closed

Remove no-op overrides and deduplicate Dag run lookup in airflowctl#70898
rjgoyln wants to merge 1 commit into
apache:mainfrom
rjgoyln:cleanup/airflowctl-dead-code-and-dag-run-lookup

Conversation

@rjgoyln

@rjgoyln rjgoyln commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

Three cleanups in airflow-ctl, all behaviour-preserving.

1. client.py — a no-op re-raise. get_client caught AirflowCtlNotFoundException only to raise e unchanged. This is the same pattern removed from the operations layer in #70376; this one survived because it sits in client.py rather than operations.py. The exception is still handled by safe_call_command in cli_config.py, and api_client.close() still runs in the surviving finally.

2. cli_config.py — a redundant override. DefaultHelpParser._check_value only called super(). airflow-core's namesake does real work (check_legacy_command), but airflow-ctl deliberately has no legacy-command mapping, so this was a degenerate copy of it.

3. dag_command / task_command — a duplicated Dag run lookup. Both commands carried a near-identical logical-date lookup, each preceded by the same run-selector guard. Guard and lookups now live in ctl/utils/dag_run.py.

Why two resolvers rather than one

task_command must not fetch the Dag run when a run_id is supplied. Doing so would add an HTTP request that did not previously happen, and would re-attribute a 404 from Task instance … not found to Dag run … not found. So resolve_dag_run_id takes a supplied run_id at face value, while resolve_dag_run (used by dags state, which needs the response body either way) fetches it. They share the selector guard and the logical-date lookup, so no duplication survives the split.

The two added assertions pin that invariant down — without them, a future "these two look the same, merge them" cleanup would silently add a request and swap the error message.

Notes

  • No behaviour change is intended anywhere; error strings and exit paths are unchanged.
  • No newsfragment: airflow-ctl release managers regenerate the changelog from git log.

Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

Three pieces of airflowctl did nothing but obscure the code around them: an
except clause that re-raised its exception unchanged, an argparse override
that only called super(), and a Dag run lookup that existed in two commands.
The re-raise is the same pattern cleaned out of the operations layer in
apache#70376; it survived there because it sits in client.py instead.

Sharing the lookup also lets the run selector validation live in one place
rather than being repeated in front of every command that accepts one.

A supplied run_id is deliberately still taken at face value rather than
fetched, so commands acting on a nested resource keep reporting a miss
against that resource instead of against the Dag run. The added assertions
pin that down, since collapsing the two resolvers would otherwise silently
add a request and re-attribute the 404.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant