Would it be also be a good iea to change the default configuration of new installations to require an explicit value?
The situation to me seems a bit like the default DAG schedule, which used to be timedelta(days=7) (IIRC), which nobody found useful. We migrated the default to None in Airflow 3. Having None in sensor timeout makes no sense, and we already have a config for this, so the situation here is much better the DAG schedule. We only need to change the default in a minor version, which shouldn’t be breaking (existing installations keep their existing configuration when upgrading). TP > On Sep 25, 2026, at 16:20, Amogh Desai <[email protected]> wrote: > > Hi All, > > `BaseSensorOperator` > <https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/sensors.html#basesensoroperator-parameters> > defaults > to `timeout=None` and falls back to `[sensors] default_timeout`, whose > packaged > default is seven days. A sensor waiting on something that never arrives > holds a worker slot for a week before failing, > and the retry starts the wait again. Nothing about this warns the Dag > author. > > I propose that we catch this at parse time, so authors see the message the > moment the Dag file loads in the Dag processor > rather than after the first week burns. > > My proposal's quite simple: > - Emit a warning at parse time when a sensor is instantiated without an > explicit `timeout`. > - Stay quiet when the deployment has already changed the default timeout. > If they set it, assume that they have thought about it. > - Give deployments a config knob to silence the warning entirely (but > default to *warning them*) > - Apply to every sensor mode. Seven days of reschedule or a wrongly set > trigger timeout still seems broken. > - Keep the message agnostic on what value to pick; focus on warning, not a > suggestion. > > No runtime behavior change. Existing Dags keep the seven day default and > see the message. > > I also have one question: > Should we also ship the UI surface(a new `DagWarningType` so it appears on > the Dags list banner) or just a Dag processor warning? > (It's a question of noise vs. spread here) > > Once I have enough feedback here, I will proceed with a PR. > > Thanks & Regards, > Amogh Desai --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
