ignacioparicio commented on issue #72514: URL: https://github.com/apache/airflow/issues/72514#issuecomment-5652498844
@bingqin2 thanks! I'm not working on the task or task-group follow-up and this looks complementary to https://github.com/apache/airflow/pull/72517, so please go ahead. At first glance, reusing the task instances created for the awaited run looks like the right direction to me. Maybe one question before implementation: in case 2, if `_create_orm_dagrun` creates the run and calls `verify_integrity()` in the same transaction, when can the run be visible without its task instances? If that cannot happen, wouldn't a run with no task instances be enough to conclude that the requested task is not part of that run, rather than continuing to wait? Am I missing another Dag-run creation path? <details> <summary> A second concern on `_get_group_tasks` </summary> Note: this was AI-assisted and I only checked superficially myself, so I'm folding it in a collapsible. `_get_group_tasks` resolves the task group from the latest Dag version, not the version used by the awaited run. I agree that this is an existing server-side limitation as per your post, but I am not sure it can be left for later if this change is meant to complete the task-group existence check. The reason is that a group that existed in the awaited run but was later renamed or removed would still be reported as missing. </details> -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
