Fix airflowctl always using production creds when --env is passed - #70584
Open
bujjibabukatta wants to merge 1 commit into
Open
Fix airflowctl always using production creds when --env is passed#70584bujjibabukatta wants to merge 1 commit into
bujjibabukatta wants to merge 1 commit into
Conversation
bujjibabukatta
requested review from
bugraoz93,
dheerajturaga,
henry3260 and
potiuk
as code owners
July 28, 2026 09:51
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ran into this while poking around the CLI — turns out --env/-e is accepted by pretty much every airflowctl command, but it's basically decorative outside of auth login. Everything else (dags list, connections list, dags trigger, you name it) quietly ignores it and talks to production no matter what you pass.
The reason is that provide_api_client's wrapper only ever forwards api_token down to get_client(), and get_client() doesn't even accept an environment argument. So Credentials falls back to its own default of "production" every single time, regardless of what you typed. auth login works fine because it builds Credentials directly with api_environment=args.env — it just never went through this shared path.
Practically, this means something like airflowctl dags trigger --env staging some_dag looks like it's targeting staging, but it's actually hitting production with whatever token happens to be sitting in the production keychain entry. Best case you get a confusing Token Expired/Invalid JWT error. Worst case it silently works — against the wrong environment.
Fix is pretty small: get_client() now takes an api_environment param, and provide_api_client reads args.env and passes it through, same as auth login already does. While I was in there I noticed version_command.py had the exact same bug on its own direct get_client() call for version --remote --env ..., so fixed that too.
AIRFLOW_CLI_ENVIRONMENT still takes priority over --env if both are set — that precedence already lived inside Credentials.init and I didn't touch it.
Added tests for both get_client (spins up real per-environment config files and checks it resolves the right one) and provide_api_client, which didn't actually have any direct test coverage before this.
Closes #70519
AI Disclosure
Model(s) used: Claude
AI was used for:
The implementation and code changes were developed and validated by me.