Apache Airflow version

main branch (observed from the current main source on May 24, 2026)

What happened

airflow dags next-execution --table can crash when there is no next scheduled run.

This happens because the command's iterator can yield None, but the --table path applies operator.attrgetter(...) to every yielded object without guarding that sentinel first.

The non-table path already handles this case by printing:

• [WARN] No following schedule can be found. This DAG may have schedule interval '@once' or None.
• None

So this looks like a regression in the table-output branch rather than intended behavior.

This appears to have been introduced when partition-related next-execution enhancements landed in #62463 on March 3, 2026. An older bug in the non-table path was previously handled in #30117, and the current non-table path still behaves correctly for None.

What you think should happen instead

--table should not crash.

It should mirror the existing non-table None handling, or otherwise stop before trying to read attributes from None.

How to reproduce

One reproducer is a DAG with schedule=None:

from airflow import DAG
from pendulum import datetime

with DAG(
    dag_id="no_schedule_next_execution",
    start_date=datetime(2025, 1, 1, tz="UTC"),
    schedule=None,
):
    pass

Then run:

airflow dags next-execution no_schedule_next_execution --table

Another reproducer is an @once DAG when requesting more than one execution:

airflow dags next-execution my_once_dag --num-executions 2 --table

Additional details

The core issue is that iter_next_dagrun_info() can yield DagRunInfo | None, and the table branch builds rows with attribute getters directly over the iterator output.

The same command's non-table branch already contains the expected if info is None guard and warning message, so the table branch looks inconsistent with existing command behavior.

Are you willing to submit PR?

Yes, if helpful.

Code of Conduct

• I agree to follow this project's Code of Conduct