Fix airflow users reset-password in FAB CLI (#63830)

[deepujain]

Summary

airflow users reset-password in Airflow 2.11.2 can fail because the command looks up the user in one Flask app context and then resets the password in a different one. This change keeps the lookup and password reset inside the same application builder context so the security manager uses a fully initialized SQLAlchemy extension.

Changes

• providers/fab/src/airflow/providers/fab/auth_manager/cli_commands/user_command.py -- refactored user lookup so user_reset_password() resolves the user and performs the password reset inside a single get_application_builder() context.
• providers/fab/tests/unit/fab/auth_manager/cli_commands/test_user_command.py -- added a regression test that verifies user_reset_password() only opens one application builder context while resetting the password.

Test plan

• uv run --project /Users/dejain/nvidia/oss/airflow-63830/providers/fab pytest /Users/dejain/nvidia/oss/airflow-63830/providers/fab/tests/unit/fab/auth_manager/cli_commands/test_user_command.py -k 'reset_user_password' -xvs
• ruff check /Users/dejain/nvidia/oss/airflow-63830/providers/fab/src/airflow/providers/fab/auth_manager/cli_commands/user_command.py /Users/dejain/nvidia/oss/airflow-63830/providers/fab/tests/unit/fab/auth_manager/cli_commands/test_user_command.py
• ruff format --check /Users/dejain/nvidia/oss/airflow-63830/providers/fab/src/airflow/providers/fab/auth_manager/cli_commands/user_command.py /Users/dejain/nvidia/oss/airflow-63830/providers/fab/tests/unit/fab/auth_manager/cli_commands/test_user_command.py
• CI passes (ruff, mypy, pytest)

Evidence it works

• The targeted reset-password unit test selection passed locally with 3 passed, 22 deselected.
• The new regression test asserts that user_reset_password() uses a single application builder context, which matches the root cause described in the issue discussion.

Fixes #63830

[deepujain]

Pushed the fix for the FAB reset-password regression. The change keeps lookup and password reset in the same appbuilder context, and the targeted FAB reset-password tests plus ruff checks all passed locally.

[kalluripradeep]

Fix looks correct — keeping the lookup and reset in the same app context makes sense. Just noticed the celery integration test is failing, worth a quick check to confirm it's unrelated before merging.

[deepujain]

Validation update after rebasing this PR on main:

• I reran the closest local checks for the FAB CLI change and they passed:
  • uv run --project providers/fab pytest providers/fab/tests/unit/fab/auth_manager/cli_commands/test_user_command.py -k 'reset_user_password' -xvs (3 passed, 22 deselected)\n - ruff check on the changed FAB CLI files\n - ruff format --check on the changed FAB CLI files\n- I force-pushed the existing PR branch so CI reruns on the rebased code.\n\nI also checked the previous failing Integration: providers celery job. The failure was a runtime httpx.ConnectError: [Errno 111] Connection refused coming from the celery/task-sdk execution path (celery_executor_utils.py / task-sdk API client / supervisor), not from the FAB auth-manager files changed in this PR, so it looked unrelated to this branch. The rerun from this push should give us a cleaner signal on the current head.

[Nataneljpwd]

Looks great!

[Dev-iL]

Do we know if this issue affects 3.x too?

[potiuk]

This PR should be done with v2-11-test as target. You can test it there using breeze uv tool install -e ./dev/breeze --force followed by breeze start-airflow in that branch. Both airflow 2.11 and fab provider that support airflow 2.11.2 are built from that branch.

Please re-do it.

[deepujain]

Replying to the 3.x question: I do not have a separate user reproduction on a released 3.x build, but the broken code path is present on current main before this fix. In providers/fab/.../user_command.py, user_reset_password() still looked the user up via one get_application_builder() context and then called reset_password() inside a second one, which is the same pattern that triggers the SQLAlchemy / Flask app-context error reported for 2.11.x.

So this is partly observed and partly inference:

• observed: the issue is reproduced by reporters on 2.11.1 and 2.11.2
• observed: the same broken two-context implementation was still on main before this PR
• inference: the bug should affect 3.x FAB CLI as well unless another surrounding change masks it in a particular environment

That is why I targeted main here rather than treating it as 2.11-only.

[deepujain]

Redid this on v2-11-test as requested and kept the same PR thread.

What changed in the redo:

• I force-pushed the branch rebased onto v2-11-test and changed the PR base from main to v2-11-test.
• The fix is now applied to the 2.11 branch paths (airflow/providers/fab/... and tests/providers/fab/...) instead of the main-branch provider layout.
• The branch-local file checks passed after the port:
  • ruff check airflow/providers/fab/auth_manager/cli_commands/user_command.py tests/providers/fab/auth_manager/cli_commands/test_user_command.py
  • ruff format --check airflow/providers/fab/auth_manager/cli_commands/user_command.py tests/providers/fab/auth_manager/cli_commands/test_user_command.py

Validation note:

• I also attempted the requested real-environment validation with uv tool install -e ./dev/breeze --force followed by breeze start-airflow ..., but the run is currently blocked on this machine because Docker is not running (Cannot connect to the Docker daemon at unix:///Users/dejain/.docker/run/docker.sock).
• I attempted the targeted branch-local pytest path as well, but local DB initialization on this machine is currently failing in v2-11-test with a SQLite migration error unrelated to this FAB CLI change (foreign key mismatch - "deadline_alert" referencing "serialized_dag").

So the PR is now redone on the correct target branch