luc-pimentel opened a new issue, #74428:
URL: https://github.com/apache/airflow/issues/74428
### Under which category would you file this issue?
Airflow Core
### Apache Airflow version
3.3.2; also reproduced on main (3.4.0 development) on October 5, 2026.
### What happened and how to reproduce it?
### Under which category would you file this issue?
Airflow Core
### Apache Airflow version
3.3.2; also reproduced on main (3.4.0 development) on October 5, 2026.
### What happened and how to reproduce it?
With `use_job_schedule=True`, an `AssetOrTimeSchedule` Dag accepts
`allowed_run_types=["asset_triggered", "manual"]`, but the scheduler repeatedly
selects it for scheduled-run creation and logs:
```text
Dag does not allow scheduled runs; skipping
```
Ten such Dags fill the default `[scheduler]
max_dagruns_to_create_per_loop=10` batch and prevent an unrelated cron Dag from
getting scheduled runs.
On a fresh SQLite/LocalExecutor installation, save this file in the
configured Dags folder:
```python
import pendulum
from airflow.providers.standard.operators.bash import BashOperator
from airflow.sdk import DAG, Asset, AssetOrTimeSchedule, CronTriggerTimetable
A = Asset(name="probe_restricted_a", uri="probe://restricted/a")
with DAG(
dag_id="producer",
schedule=None,
start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
catchup=False,
) as producer:
BashOperator(task_id="produce", bash_command="echo produced",
outlets=[A])
with DAG(
dag_id="victim_cron",
schedule="* * * * *",
start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
catchup=False,
) as victim:
BashOperator(task_id="t", bash_command="echo victim")
for i in range(10):
with DAG(
dag_id=f"restricted_or_{i}",
schedule=AssetOrTimeSchedule(
timetable=CronTriggerTimetable("* * * * *", timezone="UTC"),
assets=[A],
),
start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
catchup=True,
allowed_run_types=["asset_triggered", "manual"],
) as restricted:
BashOperator(task_id="t", bash_command="echo restricted")
globals()[restricted.dag_id] = restricted
```
Start Airflow with:
```sh
export AIRFLOW__CORE__LOAD_EXAMPLES=False
export AIRFLOW__CORE__DAGS_ARE_PAUSED_AT_CREATION=False
export AIRFLOW__CORE__EXECUTOR=LocalExecutor
export AIRFLOW__DAG_PROCESSOR__REFRESH_INTERVAL=5
export AIRFLOW__SCHEDULER__USE_JOB_SCHEDULE=True
airflow standalone
```
After all 12 Dags are parsed and unpaused, wait three minutes. Then run
`airflow dags trigger producer` and wait for its task and the asset-triggered
runs to finish. Finally, pause the restricted Dags and wait another 150 seconds:
```sh
for i in $(seq 0 9); do
airflow dags pause "restricted_or_$i"
done
```
| Observation | 3.3.2 | main, tested October 5 |
| --- | --- | --- |
| Restricted Dags active for three minutes | `victim_cron`: 0 scheduled runs
| 0 scheduled runs |
| One producer asset event | 10 successful asset-triggered runs;
`victim_cron` still 0 | same |
| Restricted Dags paused | scheduled runs resume within 11 seconds; 4 runs
after 150 seconds | within 35 seconds; 5 runs after 150 seconds |
| Skip warnings before pausing | 2,651 in 4 min 07 s | 3,363 in 5 min |
The restricted Dags’ `next_dagrun` and `next_dagrun_create_after` stay at
January 1, 2026. `catchup=True` keeps their due dates earlier than the cron
Dag’s so batch ordering is deterministic. No production-code patches were used.
### What you think should happen instead?
With scheduling enabled, a Dag that disallows scheduled runs should not
prevent unrelated Dags from receiving their permitted scheduled runs or
repeatedly occupy the creation batch.
In `airflow-core/src/airflow/models/dag.py`, `DagModel.dags_needing_dagruns`
limits time-due candidates before the scheduled-run allow-list check.
`SchedulerJobRunner._create_dag_runs` in
`airflow-core/src/airflow/jobs/scheduler_job_runner.py` then skips them without
updating their due dates, so they are selected first again on the next loop.
### Operating System
macOS 26.2, Python 3.12.11 for 3.3.2; Linux/Breeze, Python 3.10.21 for main.
### Deployment
Virtualenv installation
### Versions of Apache Airflow Providers
`apache-airflow-providers-standard==1.19.0` with 3.3.2; standard provider
from source on main.
### Anything else?
A focused scheduler test also reproduces the failure on main with one
restricted Dag and a creation-batch size of 1: the unrelated time-based Dag has
no run after two loops. The existing adjacent scheduling test passes.
No duplicate found in open/closed issue and PR searches for
`allowed_run_types`, `AssetOrTimeSchedule`, and the warning text. #49508 and
its open PR #64109 concern existing queued runs rather than scheduled-run
creation.
### Are you willing to submit PR?
No. I am reporting the bug and am not planning to submit a PR.
### Code of Conduct
- [x] I agree to follow this project’s [Code of
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md).
---
Drafted-by: OpenCode 1.18.35 (GPT-6.1); reviewed by @luc-pimentel before
posting
### What you think should happen instead?
_No response_
### Operating System
_No response_
### Deployment
None
### Apache Airflow Provider(s)
_No response_
### Versions of Apache Airflow Providers
_No response_
### Official Helm Chart version
Not Applicable
### Kubernetes Version
_No response_
### Helm Chart configuration
_No response_
### Docker Image customizations
_No response_
### Anything else?
_No response_
### Are you willing to submit PR?
- [ ] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of
Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
--
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]
