[henry3260]

Why

The pending partitioned Dag run detail response (GET /ui/partitioned_dag_runs/{dag_id}/pending)
carries two asset-bearing fields. asset_expression is scoped to the assets the caller may read;
the sibling assets array was not. The query that builds it
(routes/ui/partitioned_dag_runs.py) filters on nothing but DagScheduleAssetReference.dag_id,
so every asset the Dag schedules on comes back with its full name and uri.

That makes one payload contradict itself — it can blank an asset inside the boolean tree while
spelling its name and uri out one key over:

{
  "assets": [{"asset_id": 7, "asset_name": "sales_daily", "asset_uri": "s3://bucket/sales"}],
  "asset_expression": {"asset": {"group": "asset", "hidden": true, "id": null, "name": null, "uri": null}}
}

The route's own asset dependency does not close the gap: requires_access_asset(method="GET")
reads asset_id from the path (core_api/security.py), and this route has none, so it asks the
coarse "may you read assets at all" question rather than "may you read asset #7".

Reachability is the same as for the expression redaction: with FAB or SimpleAuthManager every
asset id is authorized, so nothing changes in a stock deployment. The gap is reachable by a
third-party auth manager that implements per-asset filter_authorized_assets.

What

Backend — airflow-core/src/airflow/api_fastapi/core_api/:

• datamodels/ui/partitioned_dag_runs.py: PartitionedDagRunAssetResponse.asset_id, .asset_name
  and .asset_uri become nullable and a hidden flag is added, mirroring the shape
  redact_asset_expression already produces for the sibling field.
• routes/ui/partitioned_dag_runs.py: blanks those three fields and sets hidden for an asset
  outside ReadableAssetsFilterDep. The redaction lands on the response only — the row is still
  read in full, because the rollup mapper is keyed by the asset's real name and uri and the
  received-key lookup by its real id. readable_asset_ids is hoisted so the assets loop and the
  asset_expression call share it; no extra query.

Deliberately kept: received_count, required_count, received_keys and required_keys of a
blanked asset. They describe the Dag's own schedule, which a caller who reached this endpoint can
already read, and dropping them would leave a stuck run with no explanation at all. The run's
total_required / total_received therefore stay accurate.

Frontend — airflow-core/src/airflow/ui/:

• src/components/AssetProgressCell.tsx renders a lock icon and a muted "Hidden asset" label in
  place of the asset link for a hidden asset, and drops hidden assets from the events list it
  feeds AssetExpression (a blanked asset has no id to match an expression leaf on, and the leaf
  it would have matched is redacted to id: null anyway).
• public/i18n/locales/en/common.json: adds expression.hiddenAsset.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)