Status of testing of Apache Airflow CTL 0.1.4rc2

[potiuk]

We are kindly requesting that contributors to Apache Airflow CTL RC 0.1.4rc2 help test the RC.

Please let us know by commenting if the issue is addressed in the latest RC.

• fix(api): allow null dag_run_conf in BackfillResponse serialization (#63259): @Lee-W @YoannAbriel @atul-astronomer
  Linked issues:
  • Serialization error on accessing backfills (#63257)
• Python 3.14 Support (#63520): @Dev-iL
• Fix airflowctl boolean flags on Python 3.14 (#63587): @Dev-iL
• Add *.iml to .gitignore in all distributions (#63636): @potiuk
• Add DagRunType for operator (#63733): @henry3260
• Fix airflowctl version command prompting for keyring credentials (#63772): @dheerajturaga
• fix dagrun list limit (#64071): @henry3260 @yzhangyext
  Linked issues:
  • airflowctl: dagrun list --limit=N returns more results than limit number (#64066)
• Clear, Mark Success/Fail and delete multiple Task Instances (#64141): @jscheffl @shubhamraj-git
  Linked issues:
  • UI - Clear/Mark Success/Fail multiple Task Instances from multi-select (#63855)
• fix: use Dag form when materializing asset (#64211): @Lee-W @atul-astronomer
  Linked issues:
  • No option to provide partition key while materialising an asset (#63807)
• [main] Upgrade important CI environment (#64239): @Lee-W
• Add 4-day cooldown for uv dependency resolution (#64249): @potiuk
• Fix variable import to correctly handle falsy values (#64362): @henry3260
• Allow direct execution from airflowctl via uvx (#64406): @jscheffl
  Linked issues:
  • Allow direct execution from airflow standalone via uvx (#64405)
• Fix silent CI failures on connection import (#64416): @henry3260
• CI: Upgrade important CI environment (#64451): @jason810496
• fix infinite loop for limit<0 for all list operations in airflowctl (#64582): @rjgoyln
• Incorrect fallback logic (#64586): @rjgoyln
• Prevent path traversal via AIRFLOW_CLI_ENVIRONMENT in airflowctl (#64618): @rjgoyln
• Add is_backfillable property to DAG API responses (#64644): @Dev-iL
• Fix list-envs auth status for env names containing .json (#64677): @henry3260 @potiuk
• Run non-provider mypy as regular prek static checks instead of separate CI jobs (#64780): @potiuk
• Add cursor based pagination for get_task_instances endpoint (#64845): @pierrejeambrun
• Fix ruff on client-py (#64868): @jscheffl
• Added plugins command to airflowctl (#64935): @justinpakzad @bugraoz93
  Linked issues:
  • Add plugins command into airflowctl via operations (#64925)
• Fix CLI error handling and exit codes for failed commands (#65052): @rjgoyln
• fix(cli): change is_alive default to None in jobs list (#65065): @rjgoyln
• Add YAML-based help texts for auto-generated airflowctl commands (#65073): @justinpakzad @bugraoz93
  Linked issues:
  • Improve Help Texts in airflowctl (#57632)
• Prepare airflow-ctl 0.1.4rc1 release (#65468): @potiuk
• Fix airflow-ctl missing pyyaml runtime dependency (#65489): @justinpakzad @potiuk
  Linked issues:
  • Add YAML-based help texts for auto-generated airflowctl commands (#65073)

Thanks to all who contributed to the release (probably not a complete list!):
@potiuk @bugraoz93 @henry3260 @atul-astronomer @dheerajturaga @Lee-W @pierrejeambrun @jscheffl @rjgoyln @justinpakzad @shubhamraj-git @Dev-iL @YoannAbriel @jason810496 @yzhangyext

[Dev-iL]

Add is_backfillable property to DAG API responses (#64644): @Dev-iL

Is it not a problem that this change targets airflow-core 3.3.0?

[srchilukoori]

RC Testing Results — apache-airflow-ctl 0.1.4rc2

Environment: Breeze (Docker), Python 3.10, SQLite backend
Date: 2026-04-19
Install note: Required httpx==0.28.1 pin — RC ships httpx==1.0.dev3 which removed HTTPStatusError, crashing on startup.

uv tool install 'apache-airflow-ctl==0.1.4rc2' --prerelease=allow --with 'httpx==0.28.1' --force-reinstall

PR	Fix	Result	Notes
#63772	version no keyring prompt	✅ Pass	Returns immediately, no credential prompts
#64071	--limit returns ≤N results	✅ Pass	Verified with 7 queued runs: --limit 2 → 2 rows, --limit 5 → 5 rows
#64582	Negative --limit no infinite loop	✅ Pass	Exits in <1s; API validates and rejects -1 cleanly
#65052	Non-zero exit on failure	✅ Pass	dags get --dag-id nonexistent-dag exits 1
#65065	jobs list is_alive default	✅ Pass	Returns DagProcessorJob, SchedulerJob, TriggererJob without error
#64935	plugins list command exists	✅ Pass	Returns plugin list
#63259	Backfill no serialization error	✅ Pass	backfill list returns empty list cleanly
#63733	run_type in dag-run response	✅ Pass	run_type: "manual" present in dagrun list response
#64362	Variable falsy values preserved	✅ Pass	"0" → "0" and "false" → "false" on create + get

---

New bug found: dagrun list crashes without --state

Command: airflowctl dagrun list --limit 5

Error:

Server error: Invalid value for state. Valid values are queued, running, success, failed

Root cause: DagRunOperations.list() declares state: str as a required parameter with no default. When --state is omitted, argparse passes None. The operation unconditionally converts it with str(state) (line 630 of operations.py), which produces the literal string "None" — an invalid state value that the API rejects.

Reproduce:

airflowctl dagrun list --limit 5
# → Server error: Invalid value for state. Valid values are queued, running, success, failed

Fix: Change the state parameter to optional and skip it when not provided:

# operations.py, DagRunOperations.list()
def list(self, state: str | None = None, limit: int = 100, ...):
    params: dict[str, Any] = {"limit": limit}
    if state is not None:
        params["state"] = state

Workaround: Pass --state explicitly, e.g. airflowctl dagrun list --state running --limit 5.

Note: This also means --limit and --limit=-1 tests for PRs #64071 and #64582 required --state to be passed explicitly to isolate those behaviors.

---

Generated with assistance from Claude (Anthropic). All commands run and verified manually against a live Breeze environment.

[potiuk]

Install note: Required httpx==0.28.1 pin — RC ships httpx==1.0.dev3 which removed HTTPStatusError, crashing on startup.

That's interesting - it likely means we will have to upper bind it or pin it (BTW. You do not need to use pre-release flag - you can just install the version with ==0.1.4rc2 - then it will not use the pre-release httpx.

Add is_backfillable property to DAG API responses (#64644): @Dev-iL
Is it not a problem that this change targets airflow-core 3.3.0?

This is a good question - and one of the problems that we anticipated might happen @bugraoz93 ? It was supposed to be backwards compatible, so the question is whether it is and how.

I thought about relesing from v3-2-0-test - but it has a bit different issue, there 3.2.0-test is just a "test" branch that shoudl be actually reviewed before merging withv3-2-0-stable so maybe we need some kind of airfflow-ctl/v-1-4-test and stable ? I'd love to hear your thougts on it @bugraoz93 :) ?

[justinpakzad]

My changes are all good!

[bugraoz93]

Install note: Required httpx==0.28.1 pin — RC ships httpx==1.0.dev3 which removed HTTPStatusError, crashing on startup.

That's interesting - it likely means we will have to upper bind it or pin it (BTW. You do not need to use pre-release flag - you can just install the version with ==0.1.4rc2 - then it will not use the pre-release httpx.

Yes, indeed. Pinning or capping with highest version until we are compatible with newer versions sounds great!

Add is_backfillable property to DAG API responses (#64644): @Dev-iL
Is it not a problem that this change targets airflow-core 3.3.0?

This is a good question - and one of the problems that we anticipated might happen @bugraoz93 ? It was supposed to be backwards compatible, so the question is whether it is and how.

I thought about relesing from v3-2-0-test - but it has a bit different issue, there 3.2.0-test is just a "test" branch that shoudl be actually reviewed before merging withv3-2-0-stable so maybe we need some kind of airfflow-ctl/v-1-4-test and stable ? I'd love to hear your thougts on it @bugraoz93 :) ?

That is a great question indeed :D This could be a breaking change for release from main with any 3.2.x versions if we wait to release the API side. This can impact all the airflowctl dags commands, as it has been added to most core DAGResponse model.
Not last but previous Sunday, I compared datamodels between main and v3-2-test datamodels, which were in sync #65069 and thought it is safe to release. It seems that after check and before release, this has been merged and I have missed it :D

To be honest, after hearing your thoughts on releasing from v3-2-0-test, I backported everything to be ready there :) So ideally, we are ready to release from v3-2-test and populate the release notes, etc. from main, but still have the problem of polluting the actual Airflow release commits and the flow, as you mentioned on the sync review part.
I like the idea of having separate branches for test and stable. One friction we would add is syncing Airflow core changes into airflow-ctl/v-1-4-test, but that could rather be the safer option, as we can either fast-forward core changes directly from the v3-2-test branch or cherry-pick and can revert from there when needed.

I am still even considering your last suggestion, merging releases with Airflow and TaskSDK, as we also join as RMs to core to reduce the total amount of effort to release packages. It can make this even safer and could be the safest among all, even though making releases highly coupled will also have its own cons and some effort by the side :) Of course, this requires broader discussion

First approach, your current suggestions, we can make it rather easily to have a separate test branch (as we did for Helm as well). Branching from v3-2-test to airflow-ctl/v-1-4-test and creating a stable branch from it when we release the first version from the new test branch should do the trick. I still need to check shifting integration tests, as we won't run canary other than the v3-2-test branch, which could be the only friction in my mind for shifting the release approach

[bugraoz93]

In the light of this breaking change has been merged which already carrying the risk while releasing from main. I think we should cancal the release @potiuk and decide to release it safely with compatible way from thee release approach.

I think your both suggestion looks viable. It would be still good to have independent release process to flexible release bugfixes amendments and security fixes as we can release more than Airflow core. Since the dependencies also managed separately, stayin flexible also would helps a lot with security fixes

[potiuk]

Agree. Will do the airflow-ctl/v-1-4-test and airflow-ctl/v1-4-stable mirroring the core release.

[potiuk]

#65574 @bugraoz93 -> proposed process.

[potiuk]

Thanks everyone for testing rc2! Heads up: preparing 0.1.4rc3 now — rc2 will be superseded once rc3 ships. rc3 will fix the following items surfaced here (and anywhere else):

• httpx==1.0.dev3 pulling in on --prerelease/--pre — httpx 1.0 is a ground-up API rewrite (no HTTPStatusError / ConnectError / ReadError / etc.), so installing with pre-releases crashes at import. Capping to httpx<1.0 in Cap airflow-ctl httpx dependency below 1.0 #65607. The full migration to httpx 1.x is tracked in airflow-ctl: migrate to httpx 1.x (after rewrite) #65609.
• is_backfillable on DAGResponse (Add is_backfillable property to DAG API responses #64644) — this landed on main / airflow-core 3.3.0, not v3-2-test. To avoid anchoring rc3 to changes destined for a future core minor, rc3 is being cut from the new airflow-ctl/v0-1-stable branch (branching guidance updated in Airflow-ctl release docs: branch from core vX-Y-stable, not vX-Y-test #65606), which is anchored to v3-2-stable (what 3.2.1 actually ships).
• airflowctl dagrun list crashing without --state — fixed in Fix airflowctl dagrun list crash when --state is omitted #65608. state is now truly optional and no longer serialized as "None" into the query string. Added a regression test.
• Release strategy — rc3 is the first airflow-ctl release to use the dedicated airflow-ctl/v0-1-test / airflow-ctl/v0-1-stable branch pair (Release airflow-ctl from dedicated airflow-ctl/vX-Y-* branches #65574). Branch protection for -stable is in Protect airflow-ctl/v0-1-stable and wire up backport label #65610.

Once those five PRs land on main, the code fixes (B/C) will be cherry-picked onto airflow-ctl/v0-1-test, synced to -stable, and tagged as airflow-ctl/0.1.4rc3. I'll post a fresh testing-status issue with the rc3 tag and notify here.