You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "fat-catTW (via GitHub)" <gi...@apache.org> on 2026/10/01 14:17:54 UTC

Re: [PR] Render Grid and Graph when a path leaves and re-enters a TaskGroup [airflow]

fat-catTW commented on PR #73933:
URL: https://github.com/apache/airflow/pull/73933#issuecomment-5933345574

   Thanks for working on this. 
   But I’m concerned that the current fallback may produce a misleading order beyond just breaking one edge in the group-level cycle.
   
   In the new test case:
   
   ```python
   extract >> staging >> spark_job >> mart >> publish
   ```
   
   the real task path is:
   
   ```text
   extract -> models.staging -> spark_job -> models.mart -> publish
   ```
   
   But the expected root-level order is:
   
   ```text
   extract, models, publish, spark_job
   ```
   
   That puts `publish` before `spark_job`, even though every real task path to `publish` goes through `spark_job`.
   
   I understand that once the collapsed/group-level graph has a cycle, no perfect topological order exists. But this seems potentially confusing for users because the UI may suggest that downstream work outside the cycle can happen before a task it actually depends on. More generally, since a collapsed TaskGroup can only appear once, a path like `models.staging -> spark_job -> models.mart` cannot be faithfully represented as `models -> spark_job -> models`, so the fallback can make the group look like a single execution unit before or after `spark_job`, even though only part of the group is before it.
   
   Is this tradeoff intentional? 


-- 
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: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org