Dags that are stale during Asset update have inaccurate asset scheduling

[collinmcnulty]

Apache Airflow version

2.11.0

If "Other Airflow 2/3 version" selected, which one?

No response

What happened?

A dynamically generated dag that uses Asset scheduling sometimes has a brief issue where it is not parsing correctly and Airflow marks it as stale. During the time that it is stale, one of the Assets that it needs to schedule is updated. When it starts parsing correctly again, it does not run, and instead waits until that Asset is updated again. However, this updated Asset does show in the "Dataset updates that triggered your dag run" section of the UI.

What you think should happen instead?

Instead, the Asset updates should still be counted against the stale dag such that when it is no longer stale, it can know that it can run immediately.

How to reproduce

• create a dag that uses asset scheduling
• introduce a crash bug so that the dag goes stale
• update an asset that the dag uses to schedule
• remove the crash bug
• observe that the dag does not start

Operating System

debian bullseye

Versions of Apache Airflow Providers

No response

Deployment

Astronomer

Deployment details

No response

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

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

[collinmcnulty]

The controlling code appears to be here:

airflow/airflow-core/src/airflow/assets/manager.py

Lines 170 to 172 in 5845599

	dags_to_queue_from_asset = {
	ref.dag for ref in asset_model.scheduled_dags if not ref.dag.is_stale and not ref.dag.is_paused
	}

[jroachgolf84]

I'm curious what the desired logic would be here. Is the assumption for a "stale" DAG that it will eventually become healthy again? Is "stale" some sort of a terminal state?

[Lee-W]

closed by #60022