Add producing/consuming task dependencies to AssetGraph

[guan404ming]

Related Issue

Closes #50873

Why

• The current asset graph doesn’t display data dependencies.

How

• add a toggle to switch between scheduling and data lineage gragh

demo.mov

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[bbovenzi]

Wait, so is this to show the tasks inside the Dag instead?

[guan404ming]

Yes, that’s my current understanding. Based on the discussion in the issue, it seems the intention is to show the tasks inside the dag. But I’m not completely certain, so I’m happy to adjust the implementation if needed.

[pierrejeambrun]

I think we are mixing two things and it will make the graph even more complicated for users.

• On one side we have the 'dependencies' from logical execution flow / scheduling
• On the other side we have data dependencies / lineage (which task is reading which asset event)

I'm not sure if baking those two pieces inside the same graph is a good idea. I believe it will make things hard to understand.

I assume the toggle is here for that.

Also the asset graph is really at the dag level I think. On the Dag graph on the other hand, we do have task level resolution. #51401, same for asset aliases.

Instead of having task level vs graph level, it sould be 'scheduling / execution flow' vs data dependencies

[guan404ming]

I've updated the implementation to split them into two views and add a button to switch between two different graph

Screen.Recording.2025-12-09.at.8.06.22.PM.mov

[jason810496]

Thanks for the PR.
It's really nice to see this cool feature!

[pierrejeambrun]

Nit. I'm not sure we want to call that 'lineage'. That could be 'task dependencies' or something else.

I don't want people to expect a full lineage solution, while this is for now limited to "producing/consuming task dependencies"

Also for asset alias, we might need to double check. If I run asset_alias_example_alias_producer, I see:

But I don't see any consuming tasks, even after running asset_alias_example_alias_consumer. But i'm not sure if we do have the information at this point.

[guan404ming]

But I don't see any consuming tasks, even after running asset_alias_example_alias_consumer. But i'm not sure if we do have the information at this point.

You're right. The data model doesn't currently store task-to-asset-alias relationships (only TaskInletAssetReference / TaskOutletAssetReference for actual assets). This would need new tables or querying serialized DAG data. Should we bring these in in this pr or in a follow up?

Nit. I'm not sure we want to call that 'lineage'. That could be 'task dependencies' or something else.

Make sense to me. I've updated to use the task dependencies wording.

[bbovenzi]

Looking much better.

In another PR, I think we should update the assets list and asset details pages to add scheduled as a column in the table or header card.

[guan404ming]

In another PR, I think we should update the assets list and asset details pages to add scheduled as a column in the table or header card.

Make sense to me. I could do that in a follow up.

[pierrejeambrun]

LGTM, we can improve with follow up PRs as suggested, I think it's a good base.