Resolve VariableInterval deadlines safely at DagRun creation

[seanghaeli]

Why

This re-introduces the VariableInterval resolution portion of #66608.

A DeadlineAlert configured with a VariableInterval is resolved when the scheduler creates a DagRun, inside DAG._process_dagrun_deadline_alerts (which runs under the prohibit_commit guard). Two problems are fixed:

1. Resolution goes through the full secrets chain (env vars, configured secrets backends, then the metadata DB) via a dedicated _resolve_variable_interval helper, rather than Variable.get / begin_nested. Variable.get and a SAVEPOINT release both commit on the scheduler's session, tripping prohibit_commit (UNEXPECTED COMMIT) and silently dropping deadlines for every scheduled DagRun. The helper passes the scheduler session through to the metastore backend so the DB read does not commit, and reading via the secrets chain (not the variable table directly) means AIRFLOW_VAR_* env vars and secrets-backend-backed Variables resolve too.

2. Each deadline alert is isolated with a plain try/except (deliberately not begin_nested, which would commit a SAVEPOINT and trip the same guard). Creating a deadline is auxiliary to creating the DagRun; a single bad alert — a missing/invalid backing Variable, or an undecodable serialized blob — must never abort the DagRun and stop the DAG from scheduling.

VariableInterval.resolve is split into resolve + coerce_to_timedelta so the scheduler-side reader reuses the exact same validation (including the OverflowError -> ValueError translation) without going through Variable.get.

Tests

• airflow-core/tests/unit/models/test_dagrun.py: VariableInterval resolves from a real Variable row and from an AIRFLOW_VAR_* env var; a missing Variable and an undecodable alert are isolated (DagRun still created, no Deadline row, error logged).
• task-sdk/tests/task_sdk/definitions/test_deadline.py: coerce_to_timedelta validation (non-integer, <= 0, overflow).

Verified locally in Breeze: 8 passed (dagrun deadline/variable) + 14 passed (SDK TestVariableInterval).

Generated-by: Claude Code (Opus via Claude Code) on behalf of Sean Ghaeli

[SameerMesiah97]

I did not manage to get to the tests but if I have to be honest, I think this needs a round of polish before a maintainer can review it. Conceptually, it looks correct but there are classic smells of unvetted AI-generated content such as messy code, long commnets/docstrings etc. I would convert it to draft and clean it up before requesting review.

I have left some comments.

[SameerMesiah97]

This except is too broad. If the only errors that you expect to encounter here are likely to do with _resolve_variable_interval or deserialization, why not limit it to them? Maybe something like this would be better:

except (ValueError, DeserializationError):

[SameerMesiah97]

I think you need to adjust the AI tool you are using to avoid generating these massive comments and docstrings. I would suggest the below instead:

# Deadline creation is best-effort. A failure here must not prevent the DagRun
# itself from being created. Use a plain try/except rather than
# ``session.begin_nested()`` since ``create_dagrun`` runs under
# ``prohibit_commit`` and releasing a SAVEPOINT would trip that guard.

[SameerMesiah97]

Same issue as above. I would suggest the below:

"""
Resolve a VariableInterval to a concrete timedelta at DagRun creation.

The Variable is resolved using the standard secrets lookup order. The scheduler
session is passed to the metastore backend to avoid creating a new session
during DagRun creation.

:param interval: The VariableInterval to resolve.
:param session: Scheduler session used for metadata database lookups.
:return: The resolved timedelta.
:raises ValueError: If the Variable cannot be resolved or converted to a valid
timedelta.
"""

[SameerMesiah97]

Do these imports need to be here to avoid circular imports or something like that? If not, I would move them to the top.

[SameerMesiah97]

This could be much cleaner. Please see the below:

for backend in ensure_secrets_loaded():
    value = call_secrets_backend_method(
        backend.get_variable,
        team_name=None,
        key=interval.key,
        **({"session": session} if isinstance(backend, MetastoreBackend) else {}),
    )
    if value is not None:
        return interval.coerce_to_timedelta(value)

    # Fail loudly (the per-alert ``except`` isolates it): the Variable does not exist in
    # any backend, so we cannot resolve the interval. This is not a silent skip.
    raise ValueError(
            f"VariableInterval '{interval.key}' could not be resolved from any "
            f"secrets backend, environment variable, or the metadata database"
        )