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 > > >
