Remove FastAPI upper constraint

[pierrejeambrun]

Cadwyn was fixed (zmievsa/cadwyn#305) and doesn't prevent us from upgrading to fastapi >= 0.121.0 anymore to benefit from the recently added scope feature for dependencies. (fastapi/fastapi#14262)

[pierrejeambrun]

Marked for 3.2.0, forcing people to go for fastapi>=0.121.0 probably shouldn't be hidden in a patch release. (I might as well add a significant newsfragment ?)

[potiuk]

Marked for 3.2.0, forcing people to go for fastapi>=0.121.0 probably shouldn't be hidden in a patch release. (I might as well add a significant newsfragment ?)

Good idea.

[bugraoz93]

Good idea to have a newsfragment about it

[amoghrajesh]

Sounds good.

[vincbeck]

This PR makes any task taking more than [execution_api] jwt_expiration_time (by default 10 minutes) fail because the JWT token expires without getting refreshed. Though, I do not know why.

[ashb]

@vincbeck That's.... super odd. The way the token renewal was working is that when the token was checked in the dep, if it was found to have less than 20% of the total validity left, a new one was generated and put in a specially named header

airflow/airflow-core/src/airflow/api_fastapi/execution_api/deps.py

Lines 146 to 148 in cc16dd6

	# Defined as a "mapping type", but 99.9% of the time it's a mutable dict. We catch
	# errors if not
	val.headers["Refreshed-API-Token"] = new # type: ignore[index]

Perhaps that "Defined as a "mapping type", but 99.9% of the time it's a mutable dict" is no longer true.

Oh, it should hit

airflow/airflow-core/src/airflow/api_fastapi/execution_api/deps.py

Line 133 in cc16dd6

response.headers["Refreshed-API-Token"] = new

first.

Either way, do you see anything in your logs about "Error refreshing Task JWT"?

[vincbeck]

Either way, do you see anything in your logs about "Error refreshing Task JWT"?

Nop, I only see jwt.exceptions.ExpiredSignatureError: Signature has expired and the task fails.

Given the significant written by Pierre:

FastAPI dependency is updated and lower bound set to ``0.121.0``

Airflow now requires FastAPI ``>=0.121.0`` and removes the previous upper
constraint. This aligns with FastAPI's new dependency lifecycle scopes
(e.g. request/function) that change how dependencies with ``yield`` are
exited.
See `FastAPI PR #14262 <https://github.com/fastapi/fastapi/pull/14262>`_.

I would say it is probably due to the fastapi upgrade because I can see in JWTReissuer that we do:

        try:
            yield
        finally:
            ...

[vincbeck]

Created an issue: #58775