Eason09053360 opened a new pull request, #72291: URL: https://github.com/apache/airflow/pull/72291
`airflow tasks test` never exported `AIRFLOW_TEST_MODE` unless `--env-vars` was also passed: the `os.environ.update()` call sat inside the `if args.env_vars:` guard, while the dict it writes was built outside it. The variable has been hostage to an unrelated flag since it was introduced in #7639 (2020). This matters more than it looks on Airflow 3: the `test_mode` task-context variable is currently commented out in `task_runner.py`, so `AIRFLOW_TEST_MODE` is the only working way for a task to tell it is running under a test command — and it is the only channel that crosses the process boundary into `BashOperator` shells and user subprocesses. The official `example_passing_params_via_test_command` Dag prints it and has been showing `None` the whole time. The `monkeypatch.delenv` calls in the test are load-bearing: `task_test` writes to the real process environment, so without clearing the keys first the `with-env-vars` case leaks `AIRFLOW_TEST_MODE=True` and the new case would pass against unfixed code — recreating the same blind spot. Dag code that reads `AIRFLOW_TEST_MODE` during `tasks test` will now see `True` where it previously saw nothing. --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 5) Generated-by: Claude Code (Opus 5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- 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]
