I’m already reviewing AIP-117, and I like the proposal. Its focus is on task scheduling parameters, whereas this proposal controls the timeout of the Dag run itself. By changing Dag code, I mean requiring the author to explicitly define a lookup to make the timeout configurable. IMHO, this should be a native option when creating a Dag run, with `dagrun_timeout` as the default and an optional override for that individual run, without requiring any lookup declaration or custom param handling.
On Tue, Nov 3, 2026 at 2:36 PM Elad Kalif via dev <[email protected]> wrote: > If I get it right when you create a new run you wish to submit a value that > is different from the one in the code file? > It has some similarities with AIP-117 that lays the ground for pools and > queues. I think dagrun timeout is a simpler case because it doesn't involve > the scheduler loop. > My point is that we should have the same user interface like the one > suggested in AIP-117 > > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/446071748/AIP-117+Per-Run+Task+Scheduling+Controls > > On Tue, Nov 3, 2026 at 8:53 AM Jarek Potiuk <[email protected]> wrote: > > > No problem. It's a nice "operational" improvement that makes a lot of > > sense.. > > > > On Mon, Nov 2, 2026 at 12:13 PM Hussein Awala <[email protected]> wrote: > > > > > Hi everyone, > > > > > > While working on a custom backfill DAG to trigger another DAG today, I > > was > > > surprised to find that there is no way to override the DAG-level > > > dagrun_timeout for an individual run. > > > > > > The DAG-level timeout works well for regular scheduled runs. However, > > > manual runs and custom backfills can process larger batches of data and > > > need more time. I’d like to set a different timeout for those runs > > without > > > changing the DAG definition or affecting other runs. > > > > > > I opened PR #76311 <https://github.com/apache/airflow/pull/76311> to > > > support this. The idea is straightforward: persist an optional timeout > > > override on each DAG run and have the scheduler use it when set, > falling > > > back to the DAG-level timeout otherwise. Omitting the override > preserves > > > the existing behavior. > > > > > > The diff is fairly large because the parameter needs to be supported > > across > > > the APIs, clients, UI, backfills, and SDK, along with tests and > generated > > > schemas. The core change is a nullable database column and the > scheduler > > > logic to select the effective timeout. Support in TriggerDagRunOperator > > is > > > planned as a separate follow-up. > > > > > > I’m sharing this here for visibility and to hear any objections or > > concerns > > > I may have missed. Does anyone see a problem with allowing this > override, > > > or an edge case we should consider? > > > > > > Thanks, > > > Hussein > > > > > >
