+1 to TP's suggestion of lowering the packaged default (8 hours seems sensible given the default of two retries). It's non-breaking for existing installs and addresses the worst case.
I'd hold off on the warning, banner, and suppression config until we have evidence users actually hit this though. So far it's a plausible risk, but we haven't actually seen a real report. It’s also not a given that everyone hits even if they leave the timeout empty as deferrable sensors release the worker slot while waiting. If anyone has seen this bite in production, issues, Slack threads, or even anecdotal, I’d love to hear about it, as that would change my view. Constance > On Sep 28, 2026, at 5:16 AM, Amogh Desai <[email protected]> wrote: > > 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] >> >>
