Repository navigation
Status of testing of Apache Airflow CTL 0.1.4rc2 #65497
Description
Activity
RC Testing Results — apache-airflow-ctl 0.1.4rc2
Environment: Breeze (Docker), Python 3.10, SQLite backend
Date: 2026-04-19
Install note: Requiredhttpx==0.28.1pin — RC shipshttpx==1.0.dev3which removedHTTPStatusError, crashing on startup.uv tool install 'apache-airflow-ctl==0.1.4rc2' --prerelease=allow --with 'httpx==0.28.1' --force-reinstallPR Fix Result Notes #63772 versionno keyring prompt✅ Pass Returns immediately, no credential prompts #64071 --limitreturns ≤N results✅ Pass Verified with 7 queued runs: --limit 2→ 2 rows,--limit 5→ 5 rows#64582 Negative --limitno infinite loop✅ Pass Exits in <1s; API validates and rejects -1cleanly#65052 Non-zero exit on failure ✅ Pass dags get --dag-id nonexistent-dagexits 1#65065 jobs listis_alivedefault✅ Pass Returns DagProcessorJob, SchedulerJob, TriggererJob without error #64935 plugins listcommand exists✅ Pass Returns plugin list #63259 Backfill no serialization error ✅ Pass backfill listreturns empty list cleanly#63733 run_typein dag-run response✅ Pass run_type: "manual"present indagrun listresponse#64362 Variable falsy values preserved ✅ Pass "0"→"0"and"false"→"false"on create + get
New bug found:
dagrun listcrashes without--stateCommand:
airflowctl dagrun list --limit 5Error:
Server error: Invalid value for state. Valid values are queued, running, success, failedRoot cause:
DagRunOperations.list()declaresstate: stras a required parameter with no default. When--stateis omitted, argparse passesNone. The operation unconditionally converts it withstr(state)(line 630 ofoperations.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, failedFix: Change the
stateparameter 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
--stateexplicitly, e.g.airflowctl dagrun list --state running --limit 5.Note: This also means
--limitand--limit=-1tests for PRs #64071 and #64582 required--stateto be passed explicitly to isolate those behaviors.
Generated with assistance from Claude (Anthropic). All commands run and verified manually against a live Breeze environment.
Reacted by Jarek PotiukInstall 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-stableso maybe we need some kind ofairfflow-ctl/v-1-4-testand stable ? I'd love to hear your thougts on it @bugraoz93 :) ?My changes are all good!
Reacted by Jarek PotiukInstall 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-stableso maybe we need some kind ofairfflow-ctl/v-1-4-testand 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
mainwith any3.2.xversions if we wait to release the API side. This can impact all theairflowctl dagscommands, as it has been added to most coreDAGResponsemodel.
Not last but previous Sunday, I compared datamodels betweenmainandv3-2-testdatamodels, 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 :DTo 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 fromv3-2-testand 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 intoairflow-ctl/v-1-4-test, but that could rather be the safer option, as we can either fast-forward core changes directly from thev3-2-testbranch 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-testtoairflow-ctl/v-1-4-testand 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 thev3-2-testbranch, which could be the only friction in my mind for shifting the release approachIn 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
Agree. Will do the
airflow-ctl/v-1-4-testandairflow-ctl/v1-4-stablemirroring the core release.#65574 @bugraoz93 -> proposed process.
Reacted by Bugra OzturkReacted by Bugra OzturkThanks 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.dev3pulling in on--prerelease/--pre— httpx 1.0 is a ground-up API rewrite (noHTTPStatusError/ConnectError/ReadError/ etc.), so installing with pre-releases crashes at import. Capping tohttpx<1.0in 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_backfillableonDAGResponse(Addis_backfillableproperty to DAG API responses #64644) — this landed onmain/ airflow-core 3.3.0, notv3-2-test. To avoid anchoring rc3 to changes destined for a future core minor, rc3 is being cut from the newairflow-ctl/v0-1-stablebranch (branching guidance updated in Airflow-ctl release docs: branch from core vX-Y-stable, not vX-Y-test #65606), which is anchored tov3-2-stable(what 3.2.1 actually ships).airflowctl dagrun listcrashing without--state— fixed in Fix airflowctl dagrun list crash when --state is omitted #65608.stateis 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-stablebranch pair (Release airflow-ctl from dedicated airflow-ctl/vX-Y-* branches #65574). Branch protection for-stableis 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 ontoairflow-ctl/v0-1-test, synced to-stable, and tagged asairflow-ctl/0.1.4rc3. I'll post a fresh testing-status issue with the rc3 tag and notify here.Reacted by Bugra Ozturk- added a commit that references this issue
on Apr 21, 2026 - added a commit that references this issue
on May 20, 2026
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.
Linked issues:
Linked issues:
Linked issues:
Linked issues:
Linked issues:
is_backfillableproperty to DAG API responses (#64644): @Dev-iLLinked issues:
Linked issues:
Linked issues:
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