seanmuth commented on issue #73686: URL: https://github.com/apache/airflow/issues/73686#issuecomment-5835656071
**Finding, not part of this issue's scope**: `max_active_runs <= 0` produces inconsistent, silently-broken behavior across the codebase, surfaced while responding to review on #73692. | Code path | `0` | `-1` | |---|---|---| | SQL candidate filter (`models/dagrun.py`, `num_running < max_active_runs`) — the actual promotion gate | never satisfiable → run stuck `QUEUED` forever, no error | same | | Python truthy gate (`scheduler_job_runner.py`, `if dag.max_active_runs:`) | falsy → would act "unlimited" — but dead code here, SQL filter already excluded the row | truthy → blocks (redundant with SQL filter) | | `exceeds_max_non_backfill` (`active_non_backfill_runs >= (dag_model.max_active_runs or 0)`) | always `True`, even with 0 active runs | always `True` too | Net effect: neither `0` nor `-1` "removes the limit" today — both cause a silent, permanent deadlock (Dag Runs queue up forever with zero indication why), and the persisted flag reports "at max" even when nothing is running. There's arguably no real need for an "unlimited" escape hatch at all (an absurdly high explicit value like `10000` achieves the same thing, and other bottlenecks would bite long before raw DagRun count does) — but if a deliberate design is wanted, `0` reads naturally as "never run this Dag" and `-1` as "no limit," which is not what either currently does. Filing this for visibility, not as committed follow-up work. --- Drafted-by: Claude Sonnet 5; reviewed by @seanmuth before posting -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
