SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
FixMyError.net
BigData New Added 15 October 2026

Airflow: DAG.__init__() got an unexpected keyword argument 'schedule_interval'

Airflow 3 removed the schedule_interval and timetable arguments that had been deprecated since 2.4; a DAG now takes a single schedule argument. Every DAG file written for Airflow 2 fails to import after the upgrade and shows up as a Broken DAG, even though nothing in the file changed. The same files keep working on any 2.x worker you still have running, which is why it can look intermittent during a rollout.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Which Airflow is parsing the file, and which DAGs still use the old argument?
airflow version
grep -rn 'schedule_interval\|timetable=' dags/

# Replace the argument; cron strings, presets and timedeltas all still work
# before: DAG('etl', schedule_interval='@daily', ...)
# after:  DAG('etl', schedule='@daily', ...)
sed -i 's/schedule_interval=/schedule=/' dags/*.py

# Check the rest of the Airflow 3 removals before the next upgrade
pip install ruff
ruff check dags/ --select AIR301 --preview

# Confirm the DAGs import cleanly
airflow dags list-import-errors

How to diagnose BigData errors

Distributed data errors are rarely about the line of code that threw them. An executor OOM, a failed checkpoint or a stuck consumer group are usually symptoms of data skew, insufficient partitioning, or a downstream system applying backpressure. The diagnostic instinct that pays off here is to look at the distribution of work across tasks before looking at the exception.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Open the Spark UI (or Flink dashboard) and sort tasks by duration and shuffle read size. If one task is an order of magnitude larger than the median, you have skew, not a memory shortage.
  2. Check the driver log and at least one executor log. The exception the driver reports is often a downstream consequence of the first executor failure.
  3. For streaming, measure consumer lag over time rather than at a point (kafka-consumer-groups --describe). Lag that grows linearly means throughput, lag that spikes and recovers means a poison message or a GC pause.
  4. Confirm whether the job failed or was killed. YARN, Kubernetes and Databricks all kill containers that exceed memory limits, and the resulting message looks like a crash rather than an eviction.
  5. Before increasing memory, try increasing partitions. Doubling spark.sql.shuffle.partitions is cheaper and more often correct than doubling executor memory.

Tools worth reaching for

  • Spark UI
  • kafka-consumer-groups
  • Airflow task logs
  • EXPLAIN / query profile

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

airflow.apache.org

Related BigData errors

See all 17 BigData errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.