Remove the unreachable 404 from the create Variable endpoint

[ColtenOuO]

Sumarry

Split out of the #71011 review.

Remove the unreachable 404 from the create Variable endpoint

The branch cannot be reached

Variable.set(**post_body.model_dump(), session=session)
variable=session.scalar(select(Variable).where(Variable.key==post_body.key).limit(1))
ifvariableisNone:
raiseHTTPException(status.HTTP_404_NOT_FOUND, ...)

Variable.set() upserts the row through the same session the read-back then queries, so the
read cannot come up empty. The status is also wrong on its own terms: a 404 on a create
endpoint tells a caller the variable they just created was not found.

That left the endpoint with a choice between publishing a response it can never return and
leaving its OpenAPI spec incomplete — which is what surfaced during #71011.

Why it could not simply be deleted

It was added in #56813 as part of the
SQLAlchemy 2 typing cleanup. SQLAlchemy types the method as returning an optional:

@overloaddefscalar(self, statement: TypedReturnsRows[Tuple[_T]], ...) ->Optional[_T]: ...

So variable is Variable | None, and returning it fails:

error: Incompatible return value type (got "Variable | None", expected "VariableResponse") [return-value]

The raise is what fixes that — it never returns, so mypy narrows the value to Variable
below it. Dropping the branch on its own puts the original error back.

The change

returnsession.scalars(select(Variable).where(Variable.key==post_body.key)).one()

ScalarResult.one() is typed -> _R, not -> Optional[_R], because its contract already is
"exactly one row, or raise". The invariant moves into the query instead of being asserted by
control flow, so nothing has to narrow a type and no HTTP status is spent doing it. If the
invariant were ever violated, NoResultFound surfaces as a 500, which is the honest answer
for a write that silently did not happen.

.limit(1) goes with it: Variable.key is unique=True, so .one() is already exact and
the limit would only contradict it.

Behaviour

Unchanged — the removed branch was unreachable. No spec change either: the 404 was never
declared in responses=, so the generated OpenAPI spec and UI client are untouched.

---

Important

🛠️ Maintainer triage note for @ColtenOuO · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Other failing CI checks. See docs.
• ❌ Provider tests. See docs.
• ❌ Unit tests. See docs.
• ❌ Image build. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[ColtenOuO]

rebase to lastest upstream/main and re-run the CI.

[pierrejeambrun]

LGTM, thanks

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

[ColtenOuO]

Sumarry

Split out of the #71011 review.

Remove the unreachable 404 from the create Variable endpoint

The branch cannot be reached

Variable.set(**post_body.model_dump(), session=session)
variable=session.scalar(select(Variable).where(Variable.key==post_body.key).limit(1))
ifvariableisNone:
raiseHTTPException(status.HTTP_404_NOT_FOUND, ...)

Variable.set() upserts the row through the same session the read-back then queries, so the
read cannot come up empty. The status is also wrong on its own terms: a 404 on a create
endpoint tells a caller the variable they just created was not found.

That left the endpoint with a choice between publishing a response it can never return and
leaving its OpenAPI spec incomplete — which is what surfaced during #71011.

Why it could not simply be deleted

It was added in #56813 as part of the
SQLAlchemy 2 typing cleanup. SQLAlchemy types the method as returning an optional:

@overloaddefscalar(self, statement: TypedReturnsRows[Tuple[_T]], ...) ->Optional[_T]: ...

So variable is Variable | None, and returning it fails:

error: Incompatible return value type (got "Variable | None", expected "VariableResponse") [return-value]

The raise is what fixes that — it never returns, so mypy narrows the value to Variable
below it. Dropping the branch on its own puts the original error back.

The change

returnsession.scalars(select(Variable).where(Variable.key==post_body.key)).one()

ScalarResult.one() is typed -> _R, not -> Optional[_R], because its contract already is
"exactly one row, or raise". The invariant moves into the query instead of being asserted by
control flow, so nothing has to narrow a type and no HTTP status is spent doing it. If the
invariant were ever violated, NoResultFound surfaces as a 500, which is the honest answer
for a write that silently did not happen.

.limit(1) goes with it: Variable.key is unique=True, so .one() is already exact and
the limit would only contradict it.

Behaviour

Unchanged — the removed branch was unreachable. No spec change either: the 404 was never
declared in responses=, so the generated OpenAPI spec and UI client are untouched.

---

Important

🛠️ Maintainer triage note for @ColtenOuO · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Other failing CI checks. See docs.
• ❌ Provider tests. See docs.
• ❌ Unit tests. See docs.
• ❌ Image build. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[ColtenOuO]

rebase to lastest upstream/main and re-run the CI.

[pierrejeambrun]

LGTM, thanks

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

[ColtenOuO]

Sumarry

Split out of the #71011 review.

Remove the unreachable 404 from the create Variable endpoint

The branch cannot be reached

Variable.set(**post_body.model_dump(), session=session)
variable=session.scalar(select(Variable).where(Variable.key==post_body.key).limit(1))
ifvariableisNone:
raiseHTTPException(status.HTTP_404_NOT_FOUND, ...)

Variable.set() upserts the row through the same session the read-back then queries, so the
read cannot come up empty. The status is also wrong on its own terms: a 404 on a create
endpoint tells a caller the variable they just created was not found.

That left the endpoint with a choice between publishing a response it can never return and
leaving its OpenAPI spec incomplete — which is what surfaced during #71011.

Why it could not simply be deleted

It was added in #56813 as part of the
SQLAlchemy 2 typing cleanup. SQLAlchemy types the method as returning an optional:

@overloaddefscalar(self, statement: TypedReturnsRows[Tuple[_T]], ...) ->Optional[_T]: ...

So variable is Variable | None, and returning it fails:

error: Incompatible return value type (got "Variable | None", expected "VariableResponse") [return-value]

The raise is what fixes that — it never returns, so mypy narrows the value to Variable
below it. Dropping the branch on its own puts the original error back.

The change

returnsession.scalars(select(Variable).where(Variable.key==post_body.key)).one()

ScalarResult.one() is typed -> _R, not -> Optional[_R], because its contract already is
"exactly one row, or raise". The invariant moves into the query instead of being asserted by
control flow, so nothing has to narrow a type and no HTTP status is spent doing it. If the
invariant were ever violated, NoResultFound surfaces as a 500, which is the honest answer
for a write that silently did not happen.

.limit(1) goes with it: Variable.key is unique=True, so .one() is already exact and
the limit would only contradict it.

Behaviour

Unchanged — the removed branch was unreachable. No spec change either: the 404 was never
declared in responses=, so the generated OpenAPI spec and UI client are untouched.

---

Important

🛠️ Maintainer triage note for @ColtenOuO · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Other failing CI checks. See docs.
• ❌ Provider tests. See docs.
• ❌ Unit tests. See docs.
• ❌ Image build. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[ColtenOuO]

rebase to lastest upstream/main and re-run the CI.

[pierrejeambrun]

LGTM, thanks

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

[ColtenOuO]

Sumarry

Split out of the #71011 review.

Remove the unreachable 404 from the create Variable endpoint

The branch cannot be reached

Variable.set(**post_body.model_dump(), session=session)
variable=session.scalar(select(Variable).where(Variable.key==post_body.key).limit(1))
ifvariableisNone:
raiseHTTPException(status.HTTP_404_NOT_FOUND, ...)

Variable.set() upserts the row through the same session the read-back then queries, so the
read cannot come up empty. The status is also wrong on its own terms: a 404 on a create
endpoint tells a caller the variable they just created was not found.

That left the endpoint with a choice between publishing a response it can never return and
leaving its OpenAPI spec incomplete — which is what surfaced during #71011.

Why it could not simply be deleted

It was added in #56813 as part of the
SQLAlchemy 2 typing cleanup. SQLAlchemy types the method as returning an optional:

@overloaddefscalar(self, statement: TypedReturnsRows[Tuple[_T]], ...) ->Optional[_T]: ...

So variable is Variable | None, and returning it fails:

error: Incompatible return value type (got "Variable | None", expected "VariableResponse") [return-value]

The raise is what fixes that — it never returns, so mypy narrows the value to Variable
below it. Dropping the branch on its own puts the original error back.

The change

returnsession.scalars(select(Variable).where(Variable.key==post_body.key)).one()

ScalarResult.one() is typed -> _R, not -> Optional[_R], because its contract already is
"exactly one row, or raise". The invariant moves into the query instead of being asserted by
control flow, so nothing has to narrow a type and no HTTP status is spent doing it. If the
invariant were ever violated, NoResultFound surfaces as a 500, which is the honest answer
for a write that silently did not happen.

.limit(1) goes with it: Variable.key is unique=True, so .one() is already exact and
the limit would only contradict it.

Behaviour

Unchanged — the removed branch was unreachable. No spec change either: the 404 was never
declared in responses=, so the generated OpenAPI spec and UI client are untouched.

---

Important

🛠️ Maintainer triage note for @ColtenOuO · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Other failing CI checks. See docs.
• ❌ Provider tests. See docs.
• ❌ Unit tests. See docs.
• ❌ Image build. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[ColtenOuO]

rebase to lastest upstream/main and re-run the CI.

[pierrejeambrun]

LGTM, thanks

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

[ColtenOuO]

Sumarry

Split out of the #71011 review.

Remove the unreachable 404 from the create Variable endpoint

The branch cannot be reached

Variable.set(**post_body.model_dump(), session=session)
variable=session.scalar(select(Variable).where(Variable.key==post_body.key).limit(1))
ifvariableisNone:
raiseHTTPException(status.HTTP_404_NOT_FOUND, ...)

Variable.set() upserts the row through the same session the read-back then queries, so the
read cannot come up empty. The status is also wrong on its own terms: a 404 on a create
endpoint tells a caller the variable they just created was not found.

That left the endpoint with a choice between publishing a response it can never return and
leaving its OpenAPI spec incomplete — which is what surfaced during #71011.

Why it could not simply be deleted

It was added in #56813 as part of the
SQLAlchemy 2 typing cleanup. SQLAlchemy types the method as returning an optional:

@overloaddefscalar(self, statement: TypedReturnsRows[Tuple[_T]], ...) ->Optional[_T]: ...

So variable is Variable | None, and returning it fails:

error: Incompatible return value type (got "Variable | None", expected "VariableResponse") [return-value]

The raise is what fixes that — it never returns, so mypy narrows the value to Variable
below it. Dropping the branch on its own puts the original error back.

The change

returnsession.scalars(select(Variable).where(Variable.key==post_body.key)).one()

ScalarResult.one() is typed -> _R, not -> Optional[_R], because its contract already is
"exactly one row, or raise". The invariant moves into the query instead of being asserted by
control flow, so nothing has to narrow a type and no HTTP status is spent doing it. If the
invariant were ever violated, NoResultFound surfaces as a 500, which is the honest answer
for a write that silently did not happen.

.limit(1) goes with it: Variable.key is unique=True, so .one() is already exact and
the limit would only contradict it.

Behaviour

Unchanged — the removed branch was unreachable. No spec change either: the 404 was never
declared in responses=, so the generated OpenAPI spec and UI client are untouched.

---

Important

🛠️ Maintainer triage note for @ColtenOuO · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Other failing CI checks. See docs.
• ❌ Provider tests. See docs.
• ❌ Unit tests. See docs.
• ❌ Image build. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[ColtenOuO]

rebase to lastest upstream/main and re-run the CI.

[pierrejeambrun]

LGTM, thanks

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

[ColtenOuO]

Sumarry

Split out of the #71011 review.

Remove the unreachable 404 from the create Variable endpoint

The branch cannot be reached

Variable.set(**post_body.model_dump(), session=session)
variable=session.scalar(select(Variable).where(Variable.key==post_body.key).limit(1))
ifvariableisNone:
raiseHTTPException(status.HTTP_404_NOT_FOUND, ...)

Variable.set() upserts the row through the same session the read-back then queries, so the
read cannot come up empty. The status is also wrong on its own terms: a 404 on a create
endpoint tells a caller the variable they just created was not found.

That left the endpoint with a choice between publishing a response it can never return and
leaving its OpenAPI spec incomplete — which is what surfaced during #71011.

Why it could not simply be deleted

It was added in #56813 as part of the
SQLAlchemy 2 typing cleanup. SQLAlchemy types the method as returning an optional:

@overloaddefscalar(self, statement: TypedReturnsRows[Tuple[_T]], ...) ->Optional[_T]: ...

So variable is Variable | None, and returning it fails:

error: Incompatible return value type (got "Variable | None", expected "VariableResponse") [return-value]

The raise is what fixes that — it never returns, so mypy narrows the value to Variable
below it. Dropping the branch on its own puts the original error back.

The change

returnsession.scalars(select(Variable).where(Variable.key==post_body.key)).one()

ScalarResult.one() is typed -> _R, not -> Optional[_R], because its contract already is
"exactly one row, or raise". The invariant moves into the query instead of being asserted by
control flow, so nothing has to narrow a type and no HTTP status is spent doing it. If the
invariant were ever violated, NoResultFound surfaces as a 500, which is the honest answer
for a write that silently did not happen.

.limit(1) goes with it: Variable.key is unique=True, so .one() is already exact and
the limit would only contradict it.

Behaviour

Unchanged — the removed branch was unreachable. No spec change either: the 404 was never
declared in responses=, so the generated OpenAPI spec and UI client are untouched.

---

Important

🛠️ Maintainer triage note for @ColtenOuO · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Other failing CI checks. See docs.
• ❌ Provider tests. See docs.
• ❌ Unit tests. See docs.
• ❌ Image build. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[ColtenOuO]

rebase to lastest upstream/main and re-run the CI.

[pierrejeambrun]

LGTM, thanks

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

[ColtenOuO]

Sumarry

Split out of the #71011 review.

Remove the unreachable 404 from the create Variable endpoint

The branch cannot be reached

Variable.set(**post_body.model_dump(), session=session)
variable=session.scalar(select(Variable).where(Variable.key==post_body.key).limit(1))
ifvariableisNone:
raiseHTTPException(status.HTTP_404_NOT_FOUND, ...)

Variable.set() upserts the row through the same session the read-back then queries, so the
read cannot come up empty. The status is also wrong on its own terms: a 404 on a create
endpoint tells a caller the variable they just created was not found.

That left the endpoint with a choice between publishing a response it can never return and
leaving its OpenAPI spec incomplete — which is what surfaced during #71011.

Why it could not simply be deleted

It was added in #56813 as part of the
SQLAlchemy 2 typing cleanup. SQLAlchemy types the method as returning an optional:

@overloaddefscalar(self, statement: TypedReturnsRows[Tuple[_T]], ...) ->Optional[_T]: ...

So variable is Variable | None, and returning it fails:

error: Incompatible return value type (got "Variable | None", expected "VariableResponse") [return-value]

The raise is what fixes that — it never returns, so mypy narrows the value to Variable
below it. Dropping the branch on its own puts the original error back.

The change

returnsession.scalars(select(Variable).where(Variable.key==post_body.key)).one()

ScalarResult.one() is typed -> _R, not -> Optional[_R], because its contract already is
"exactly one row, or raise". The invariant moves into the query instead of being asserted by
control flow, so nothing has to narrow a type and no HTTP status is spent doing it. If the
invariant were ever violated, NoResultFound surfaces as a 500, which is the honest answer
for a write that silently did not happen.

.limit(1) goes with it: Variable.key is unique=True, so .one() is already exact and
the limit would only contradict it.

Behaviour

Unchanged — the removed branch was unreachable. No spec change either: the 404 was never
declared in responses=, so the generated OpenAPI spec and UI client are untouched.

---

Important

🛠️ Maintainer triage note for @ColtenOuO · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Other failing CI checks. See docs.
• ❌ Provider tests. See docs.
• ❌ Unit tests. See docs.
• ❌ Image build. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[ColtenOuO]

rebase to lastest upstream/main and re-run the CI.

[pierrejeambrun]

LGTM, thanks

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

[ColtenOuO]

Sumarry

Split out of the #71011 review.

Remove the unreachable 404 from the create Variable endpoint

The branch cannot be reached

Variable.set(**post_body.model_dump(), session=session)
variable=session.scalar(select(Variable).where(Variable.key==post_body.key).limit(1))
ifvariableisNone:
raiseHTTPException(status.HTTP_404_NOT_FOUND, ...)

Variable.set() upserts the row through the same session the read-back then queries, so the
read cannot come up empty. The status is also wrong on its own terms: a 404 on a create
endpoint tells a caller the variable they just created was not found.

That left the endpoint with a choice between publishing a response it can never return and
leaving its OpenAPI spec incomplete — which is what surfaced during #71011.

Why it could not simply be deleted

It was added in #56813 as part of the
SQLAlchemy 2 typing cleanup. SQLAlchemy types the method as returning an optional:

@overloaddefscalar(self, statement: TypedReturnsRows[Tuple[_T]], ...) ->Optional[_T]: ...

So variable is Variable | None, and returning it fails:

error: Incompatible return value type (got "Variable | None", expected "VariableResponse") [return-value]

The raise is what fixes that — it never returns, so mypy narrows the value to Variable
below it. Dropping the branch on its own puts the original error back.

The change

returnsession.scalars(select(Variable).where(Variable.key==post_body.key)).one()

ScalarResult.one() is typed -> _R, not -> Optional[_R], because its contract already is
"exactly one row, or raise". The invariant moves into the query instead of being asserted by
control flow, so nothing has to narrow a type and no HTTP status is spent doing it. If the
invariant were ever violated, NoResultFound surfaces as a 500, which is the honest answer
for a write that silently did not happen.

.limit(1) goes with it: Variable.key is unique=True, so .one() is already exact and
the limit would only contradict it.

Behaviour

Unchanged — the removed branch was unreachable. No spec change either: the 404 was never
declared in responses=, so the generated OpenAPI spec and UI client are untouched.

---

Important

🛠️ Maintainer triage note for @ColtenOuO · by @potiuk · 2026-08-13 12:55 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed:

• ❌ Other failing CI checks. See docs.
• ❌ Provider tests. See docs.
• ❌ Unit tests. See docs.
• ❌ Image build. See docs.

Full list of what we check: Pull Request quality criteria.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[ColtenOuO]

rebase to lastest upstream/main and re-run the CI.

[pierrejeambrun]

LGTM, thanks

[github-actions]

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test