pierrejeambrun commented on code in PR #74609:
URL: https://github.com/apache/airflow/pull/74609#discussion_r4261382790
##########
airflow-core/src/airflow/plugins_manager.py:
##########
@@ -220,12 +221,14 @@ def _applies_to_root_models() -> dict[str, Any]:
These are the models the UI actually fetches for the ``applies_to``
context -- keep them in
step with ``AppliesToContext`` in ``src/utils/pluginAppliesTo.ts``.
"""
+ from airflow.api_fastapi.core_api.datamodels.assets import AssetResponse
from airflow.api_fastapi.core_api.datamodels.dag_run import DAGRunResponse
from airflow.api_fastapi.core_api.datamodels.dags import DAGResponse
from airflow.api_fastapi.core_api.datamodels.task_instances import
TaskInstanceResponse
from airflow.api_fastapi.core_api.datamodels.tasks import TaskResponse
return {
+ "asset": AssetResponse,
Review Comment:
I think adding `AssetResponse` here also widens
`_is_applies_to_path_known_elsewhere`, since it checks every root. Locally,
`{"group": ["sales"]}` (or `name`, `uri`, `watchers.name`) on a `dag` or
`task_instance` view used to be withheld as a misconfiguration. Now it loads
with a "skipped here" warning, so the tab shows on every Dag. No other
destination can resolve the asset record, so could we only treat a path as
known elsewhere for roots that can appear on the same page as the destination?
A test for an asset-only path on a `dag` view would pin it down.
--
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]
