Repository navigation
Conversation
The workload token minted for a queued task (or callback) had its lifetime hardcoded to [scheduler] task_queued_timeout. This coupled two unrelated concerns: how long a task can authenticate to the Execution API while queued, and how long the scheduler waits before reaping a queued task as orphaned. Raising one to tolerate queue backlog silently weakened the other. Adds [execution_api] workload_token_expiration_time as an independent, optional setting. When unset it falls back to task_queued_timeout, preserving current behavior for existing deployments; operators who want to decouple the two can now set it explicitly. Fixes apache#72469 Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015kAvbZ6SeKgp6jbGcvpXSh
boring-cyborg
Bot
added
area:ConfigTemplates
area:Executors-core
The newsfragment was numbered for an earlier PR draft and spanned multiple lines, which the newsfragment validity check rejects. Rename it to the actual PR number and condense it to a single line so the newsfragment CI checks pass.
conf.getfloat() raises AirflowConfigException when the execution_api.workload_token_expiration_time option is left unset, because the default is absent from config.yml (None) and getfloat rejects None. The config file registers the option with default ~, so read it as a string via conf.get() and convert to float only when a value is present, falling back to scheduler.task_queued_timeout otherwise.
potiuk
added
the
closed because of open PR limit
|
Hello @Kunal8954 - thank you for your contributions to Apache Airflow! The Airflow community has introduced a limit of 5 open pull requests at a time for contributors without write access to the repository. You currently have 8 open pull requests, so - as a one-time step of introducing the limit - we closed the ones where maintainers have not engaged yet:
These pull requests stay open because maintainers are already engaged in them - they count towards your limit:
This is not a judgement of you or of your changes. We never told contributors before that opening many pull requests at once was a problem, so there is nothing to feel bad about - and nothing is lost: your branches, commits and the review history stay where they are. What we ask you to do is to make your first prioritization decision: choose which of the pull requests above matter most to you, and reopen them (up to 5 open at a time, including the ones still open) with the "Reopen pull request" button or While your pull requests are waiting for review, the most valuable thing you can do is help in other ways - reviewing other contributors' pull requests, helping with issues, and taking part in the discussions on the devlist and Slack. Why we introduced the limit, what it means for you and how to reopen or restore a pull request is explained in https://github.com/apache/airflow/blob/main/contributing-docs/32_open_pull_request_limit.rst. Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting |
What
Adds a new, optional
[execution_api] workload_token_expiration_timeconfig option that controls how long a workload's JWT token (minted
when a task instance or callback is queued for an executor) stays
valid, independently of
[scheduler] task_queued_timeout.Why
Today,
BaseWorkloadSchema.generate_token()hardcodes the workloadtoken's lifetime to
[scheduler] task_queued_timeout. That value hasa second, unrelated job: it's also how long a task can sit in the
queuedstate before the scheduler's orphan-detection sweep reaps it.This forces operators into an uncomfortable tradeoff: raising
task_queued_timeoutto tolerate a longer queue backlog (e.g. underheavy load, or with a slow-starting KubernetesExecutor) also silently
extends how long a genuinely stuck task goes undetected - the exact
scenario in #72469, where a scheduler crash mid-dispatch left tasks
stuck in
queuedfor up to 10 hours before being reaped, becausetask_queued_timeouthad been raised for legitimate queue-waitreasons.
Design
[execution_api] workload_token_expiration_time(float, seconds, default unset).
_workload_token_valid_for()falls back to[scheduler] task_queued_timeout- existing deployments see nobehavior change unless they opt in.
task_queued_timeoutis no longerconsulted for token lifetime (only for its original orphan-detection
purpose).
hardcoded default (e.g.
600): if it defaulted to something shorterthan an operator's already-customized
task_queued_timeout, alegitimately-queued task's auth token could expire before the
scheduler's own orphan sweep fires, breaking task execution for
people who'd raised
task_queued_timeoutwithout knowing about thisnew option. Falling back preserves current behavior by construction.
Changes
airflow-core/src/airflow/executors/workloads/base.py: extracted_workload_token_valid_for()implementing the fallback logic usedby
generate_token()(inherited byExecuteTask,ExecuteCallback,and the connection-test workload).
airflow-core/src/airflow/config_templates/config.yml: added thenew option under
[execution_api], and cross-referenced it from[scheduler] task_queued_timeout's description.airflow-core/tests/unit/executors/test_workloads.pycovering both the fallback and the override path, plus an end-to-end
token-decoding test.
Fixes #72469
Gen-AI disclosure: used Claude Code (Anthropic) to investigate the
existing coupling, implement the change, write tests, and draft this
description.
🤖 Generated with Claude Code
https://claude.ai/code/session_015kAvbZ6SeKgp6jbGcvpXSh