Respect apps flags for api_server_command

[jason810496]

related: #52860

Why

• While working on Remove gunicorn daemonize for api-server #52860, I found that current api-server only respect --apps flag with --dev mode.
  • We use AIRFLOW_API_APPS environment to specify which apps are going to initialize in create_app call.
• Also the AIRFLOW_API_APPS env is no restored properly, we should set back to original value if it's set before the airlow api-server run.

What

• Add with_api_apps_env decorator with proper teardown
• Refactor test_api_apps_env test with more scenario including all apps currently available, dev mode or not, and original env is set or not.

[Copilot]

Pull Request Overview

This PR ensures the --apps flag is respected outside of dev mode and that the AIRFLOW_API_APPS environment variable is always restored to its original value.

• Introduces a with_api_apps_env decorator to manage setting/tearing down the env var
• Refactors api_server to use the decorator and removes inline env manipulation
• Updates test_api_server_command.py to parameterize scenarios for dev/non-dev modes and original env states

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
airflow-core/tests/unit/cli/commands/test_api_server_command.py	Parameterize and expand test_api_apps_env to cover all flag permutations and teardown
airflow-core/src/airflow/cli/commands/api_server_command.py	Add with_api_apps_env decorator, apply to api_server, remove manual env handling, update type ignore on access_log

Comments suppressed due to low confidence (1)

airflow-core/tests/unit/cli/commands/test_api_server_command.py:121

• [nitpick] The test verifies that AIRFLOW_API_APPS is cleaned up, but doesn’t assert that it was initially set to the expected value. Consider adding an assert on mock_environ.__setitem__ for the first assignment.

            api_server_command.api_server(parsed_args)

[potiuk]

I am not sure how much we want to configure apps in prod - I guess we might find it useful in some deployments. But should not we describe it in documentation why to do it and how to do it?

[kaxil]

I am not sure how much we want to configure apps in prod - I guess we might find it useful in some deployments. But should not we describe it in documentation why to do it and how to do it?

#43103 . Feel free to take it over @jason810496

[jason810496]

I am not sure how much we want to configure apps in prod - I guess we might find it useful in some deployments.

IMO, it might be useful for scaling API server for Task Execution and Core API separately or for users that just need to run Task Execution API-server solely.

But should not we describe it in documentation why to do it and how to do it?
#43103 . Feel free to take it over @jason810496

Thanks for bringing up the related issue! I will raise another for the documentation side.
This PR is more like fixing the behavior for the --apps only.

[pierrejeambrun]

Yes this is useful for people that want to deploy a standalone execution api server. (Scaling, isolation etc.)

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker c0c41ff v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[pierrejeambrun]

@jason810496 needs manual cherry picking I guess, or this fix won't be in the next patch release.

[jason810496]

Thanks for the reminder! I will raise backport PR when I back to home

[kaxil]

Cool, thanks. Please do when you get time

Thanks for the reminder! I will raise backport PR when I back to home