Thanks TP, that complements the warning and matches how we moved `schedule` on Dags.
Two things worth pinning down before I turn this into a PR: 1. Ship the warning and the default change in the same minor, or split them? Splitting gives users some room - we warn in version N and change in N +1. For users running Airflow in a containerized environment, would introducing both changes result in a silent behavior change after upgrading? 2. What does the new packaged default become? `None`, so the sensor raises at init when the caller passes nothing, is what I would prefer. A shorter number (say 3600) is softer but is the same problem at a smaller magnitude. Thanks & Regards, Amogh Desai On Fri, Sep 25, 2026 at 1:37 PM Tzu-ping Chung via dev < [email protected]> wrote: > 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] > >
