Type asset_expression in the REST API so the UI does not cast through unknown

[Anuragp22]

closes: #67692

asset_expression was declared as dict | None on the REST API response models, so the OpenAPI generator emitted { [k: string]: unknown }. The UI compensated by hand-maintaining an ExpressionType discriminated union in src/components/AssetExpression/ and casting the API value through it with no runtime check, so a change to the server shape would not be caught by the TypeScript build. This types the expression on the API side and lets the generated client describe it.

What changed:

• Added a structured AssetExpression model in datamodels/common.py: a recursive discriminated union over the five shapes BaseAsset.as_expression() produces (asset, alias, asset_ref, any, all), following the existing Annotated[Union[...], Discriminator] pattern in that module. Asset leaves carry the id that DagModelOperation.update_dag_asset_expression injects when the expression is persisted. id is optional so a row written before id-enrichment, or migrated from the pre-3.0 dataset format, still validates instead of returning a 500.
• Used the model for every response that serves the field: DAGDetailsResponse, DAGWithLatestDagRunsResponse, and both fields on the partitioned dag run responses.
• Typed the next_run_assets UI endpoint with a new NextRunAssetsResponse model in datamodels/ui/assets.py instead of a bare dict. response_model_exclude_unset=True keeps the response shape identical to before.
• Regenerated the OpenAPI spec and the TypeScript client.
• Removed the hand-maintained ExpressionType union and the casts in AssetProgressCell.tsx and AssetSchedule.tsx; the UI now consumes the generated type. The more precise types also let some now-dead defensive code in AssetExpression.tsx be removed.

For expressions produced by the current code the emitted JSON is unchanged, so this is not a breaking change for API consumers; only the declared schema becomes precise.

Tests: added test_common.py covering round-trip serialization of every variant, the optional id behaviour, and rejection of malformed shapes. Updated the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that as_expression() never produces and that the new model correctly rejects, to the real {"any": [{"asset": {...}}]} shape. The next_run_assets and dag-detail route tests pass unchanged.

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.8), reviewed and verified by the author

---

Important

🛠️ Maintainer triage note for @Anuragp22 · by @potiuk · 2026-06-12 10:47 UTC

Your review threads look addressed — please confirm this PR is ready for maintainer review confirmation.

Feedback from @bbovenzi across 3 unresolved thread(s); you've engaged with each (replies and/or pushes since).

The ball is in your court — you've been assigned to this PR. Reply yes / ready and a maintainer will pick it up from the queue.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[bbovenzi]

Thanks for this one!

Let's rebase and double check our tests. I assume we now need a valid asset_expression in our mocks or make sure our responses can handle None and undefined.

[Anuragp22]

Rebased onto main and fixed the failing tests.

The /dags failures came from the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that BaseAsset.as_expression() never produces. It was accepted while the field was an untyped dict, but the new model correctly rejects the bare leaf. I updated the fixtures to the real {"any": [{"asset": {...}}]} shape. The full api_fastapi suite passes locally.

The force-push is that rebase: I rebased onto current main to clear the merge conflict and squashed the work into a single commit (d88ce26 to 622dc91). No content changed beyond the test fixtures.

[Anuragp22]

Merged main, which now includes AIP-76 (#64571). AIP-76 rewrote the same asset_expression code, so resolving the overlap grew the diff.

What changed since the last review:

• Extended the typing to the partitioned-dag-run responses AIP-76 added (PartitionedDagRunCollectionResponse, PartitionedDagRunDetailResponse), alongside the original DAGDetailsResponse, DAGWithLatestDagRunsResponse, and NextRunAssetsResponse.

• AIP-76 builds the next_run_assets and partitioned responses from a dict via explicit constructors. Since asset_expression is now typed, those routes use model_validate({...}) so pydantic validates the stored dict into the model. This mirrors DAGDetailsResponse.model_validate(dag_model) in routes/public/dags.py and leaves AIP-76's partition logic unchanged.

• Addressed the earlier review: ExpressionType is now derived from the generated client, AssetSummary is removed, and the as ExpressionType casts in AssetProgressCell.tsx and AssetSchedule.tsx are gone. Also removed the now-unused NextRunEvent type.

• Regenerated the OpenAPI spec and TypeScript client.

[Anuragp22]

Ready for maintainer review.

Two commits since the last look:

• Fixed the ruff-format failure on partitioned_dag_runs.py, the only red check.

• Hardened the newly-typed asset_expression field against pre-3.0 migrated rows. The 2.x dataset scheduler stored shapes the 3.0 column rename carried over verbatim: a bare URI string, {"any": [<strings>]}, {"alias": "<name>"}. The typed field would return a 500 on those until the DAG is re-parsed. MaybeAssetExpression now coerces any unrecognized stored shape to null, reproducing the blank render the UI showed while the field was an untyped dict. Added round-trip and coercion tests.

I've addressed all three of bbovenzi's comments on AssetExpression/types.ts.

[Anuragp22]

ready

[potiuk]

@Anuragp22 — the Static checks CI job is failing here, which needs a code fix on your side (a rerun won't clear it). You can reproduce and fix locally with:

pre-commit run --all-files # or: breeze static-checks

Once those pass and CI is green, it'll be ready for a maintainer to pick up. Thanks!

See the PR quality criteria.

_{Automated first-pass triage note drafted by an AI-assisted tool — may get things wrong; once addressed, a real Apache Airflow maintainer takes the next look. (why automated)}

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[pierrejeambrun]

Nice, one suggestion bellow, not blocking

[pierrejeambrun]

Only 1 comments unresolved, then I believe we are good to merge.

[guan404ming]

Besides the unresolved comment, lgtm!

[pierrejeambrun]

LGTM

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 3733e62 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[Anuragp22]

closes: #67692

asset_expression was declared as dict | None on the REST API response models, so the OpenAPI generator emitted { [k: string]: unknown }. The UI compensated by hand-maintaining an ExpressionType discriminated union in src/components/AssetExpression/ and casting the API value through it with no runtime check, so a change to the server shape would not be caught by the TypeScript build. This types the expression on the API side and lets the generated client describe it.

What changed:

• Added a structured AssetExpression model in datamodels/common.py: a recursive discriminated union over the five shapes BaseAsset.as_expression() produces (asset, alias, asset_ref, any, all), following the existing Annotated[Union[...], Discriminator] pattern in that module. Asset leaves carry the id that DagModelOperation.update_dag_asset_expression injects when the expression is persisted. id is optional so a row written before id-enrichment, or migrated from the pre-3.0 dataset format, still validates instead of returning a 500.
• Used the model for every response that serves the field: DAGDetailsResponse, DAGWithLatestDagRunsResponse, and both fields on the partitioned dag run responses.
• Typed the next_run_assets UI endpoint with a new NextRunAssetsResponse model in datamodels/ui/assets.py instead of a bare dict. response_model_exclude_unset=True keeps the response shape identical to before.
• Regenerated the OpenAPI spec and the TypeScript client.
• Removed the hand-maintained ExpressionType union and the casts in AssetProgressCell.tsx and AssetSchedule.tsx; the UI now consumes the generated type. The more precise types also let some now-dead defensive code in AssetExpression.tsx be removed.

For expressions produced by the current code the emitted JSON is unchanged, so this is not a breaking change for API consumers; only the declared schema becomes precise.

Tests: added test_common.py covering round-trip serialization of every variant, the optional id behaviour, and rejection of malformed shapes. Updated the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that as_expression() never produces and that the new model correctly rejects, to the real {"any": [{"asset": {...}}]} shape. The next_run_assets and dag-detail route tests pass unchanged.

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.8), reviewed and verified by the author

---

Important

🛠️ Maintainer triage note for @Anuragp22 · by @potiuk · 2026-06-12 10:47 UTC

Your review threads look addressed — please confirm this PR is ready for maintainer review confirmation.

Feedback from @bbovenzi across 3 unresolved thread(s); you've engaged with each (replies and/or pushes since).

The ball is in your court — you've been assigned to this PR. Reply yes / ready and a maintainer will pick it up from the queue.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[bbovenzi]

Thanks for this one!

Let's rebase and double check our tests. I assume we now need a valid asset_expression in our mocks or make sure our responses can handle None and undefined.

[Anuragp22]

Rebased onto main and fixed the failing tests.

The /dags failures came from the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that BaseAsset.as_expression() never produces. It was accepted while the field was an untyped dict, but the new model correctly rejects the bare leaf. I updated the fixtures to the real {"any": [{"asset": {...}}]} shape. The full api_fastapi suite passes locally.

The force-push is that rebase: I rebased onto current main to clear the merge conflict and squashed the work into a single commit (d88ce26 to 622dc91). No content changed beyond the test fixtures.

[Anuragp22]

Merged main, which now includes AIP-76 (#64571). AIP-76 rewrote the same asset_expression code, so resolving the overlap grew the diff.

What changed since the last review:

• Extended the typing to the partitioned-dag-run responses AIP-76 added (PartitionedDagRunCollectionResponse, PartitionedDagRunDetailResponse), alongside the original DAGDetailsResponse, DAGWithLatestDagRunsResponse, and NextRunAssetsResponse.

• AIP-76 builds the next_run_assets and partitioned responses from a dict via explicit constructors. Since asset_expression is now typed, those routes use model_validate({...}) so pydantic validates the stored dict into the model. This mirrors DAGDetailsResponse.model_validate(dag_model) in routes/public/dags.py and leaves AIP-76's partition logic unchanged.

• Addressed the earlier review: ExpressionType is now derived from the generated client, AssetSummary is removed, and the as ExpressionType casts in AssetProgressCell.tsx and AssetSchedule.tsx are gone. Also removed the now-unused NextRunEvent type.

• Regenerated the OpenAPI spec and TypeScript client.

[Anuragp22]

Ready for maintainer review.

Two commits since the last look:

• Fixed the ruff-format failure on partitioned_dag_runs.py, the only red check.

• Hardened the newly-typed asset_expression field against pre-3.0 migrated rows. The 2.x dataset scheduler stored shapes the 3.0 column rename carried over verbatim: a bare URI string, {"any": [<strings>]}, {"alias": "<name>"}. The typed field would return a 500 on those until the DAG is re-parsed. MaybeAssetExpression now coerces any unrecognized stored shape to null, reproducing the blank render the UI showed while the field was an untyped dict. Added round-trip and coercion tests.

I've addressed all three of bbovenzi's comments on AssetExpression/types.ts.

[Anuragp22]

ready

[potiuk]

@Anuragp22 — the Static checks CI job is failing here, which needs a code fix on your side (a rerun won't clear it). You can reproduce and fix locally with:

pre-commit run --all-files # or: breeze static-checks

Once those pass and CI is green, it'll be ready for a maintainer to pick up. Thanks!

See the PR quality criteria.

_{Automated first-pass triage note drafted by an AI-assisted tool — may get things wrong; once addressed, a real Apache Airflow maintainer takes the next look. (why automated)}

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[pierrejeambrun]

Nice, one suggestion bellow, not blocking

[pierrejeambrun]

Only 1 comments unresolved, then I believe we are good to merge.

[guan404ming]

Besides the unresolved comment, lgtm!

[pierrejeambrun]

LGTM

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 3733e62 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[Anuragp22]

closes: #67692

asset_expression was declared as dict | None on the REST API response models, so the OpenAPI generator emitted { [k: string]: unknown }. The UI compensated by hand-maintaining an ExpressionType discriminated union in src/components/AssetExpression/ and casting the API value through it with no runtime check, so a change to the server shape would not be caught by the TypeScript build. This types the expression on the API side and lets the generated client describe it.

What changed:

• Added a structured AssetExpression model in datamodels/common.py: a recursive discriminated union over the five shapes BaseAsset.as_expression() produces (asset, alias, asset_ref, any, all), following the existing Annotated[Union[...], Discriminator] pattern in that module. Asset leaves carry the id that DagModelOperation.update_dag_asset_expression injects when the expression is persisted. id is optional so a row written before id-enrichment, or migrated from the pre-3.0 dataset format, still validates instead of returning a 500.
• Used the model for every response that serves the field: DAGDetailsResponse, DAGWithLatestDagRunsResponse, and both fields on the partitioned dag run responses.
• Typed the next_run_assets UI endpoint with a new NextRunAssetsResponse model in datamodels/ui/assets.py instead of a bare dict. response_model_exclude_unset=True keeps the response shape identical to before.
• Regenerated the OpenAPI spec and the TypeScript client.
• Removed the hand-maintained ExpressionType union and the casts in AssetProgressCell.tsx and AssetSchedule.tsx; the UI now consumes the generated type. The more precise types also let some now-dead defensive code in AssetExpression.tsx be removed.

For expressions produced by the current code the emitted JSON is unchanged, so this is not a breaking change for API consumers; only the declared schema becomes precise.

Tests: added test_common.py covering round-trip serialization of every variant, the optional id behaviour, and rejection of malformed shapes. Updated the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that as_expression() never produces and that the new model correctly rejects, to the real {"any": [{"asset": {...}}]} shape. The next_run_assets and dag-detail route tests pass unchanged.

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.8), reviewed and verified by the author

---

Important

🛠️ Maintainer triage note for @Anuragp22 · by @potiuk · 2026-06-12 10:47 UTC

Your review threads look addressed — please confirm this PR is ready for maintainer review confirmation.

Feedback from @bbovenzi across 3 unresolved thread(s); you've engaged with each (replies and/or pushes since).

The ball is in your court — you've been assigned to this PR. Reply yes / ready and a maintainer will pick it up from the queue.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[bbovenzi]

Thanks for this one!

Let's rebase and double check our tests. I assume we now need a valid asset_expression in our mocks or make sure our responses can handle None and undefined.

[Anuragp22]

Rebased onto main and fixed the failing tests.

The /dags failures came from the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that BaseAsset.as_expression() never produces. It was accepted while the field was an untyped dict, but the new model correctly rejects the bare leaf. I updated the fixtures to the real {"any": [{"asset": {...}}]} shape. The full api_fastapi suite passes locally.

The force-push is that rebase: I rebased onto current main to clear the merge conflict and squashed the work into a single commit (d88ce26 to 622dc91). No content changed beyond the test fixtures.

[Anuragp22]

Merged main, which now includes AIP-76 (#64571). AIP-76 rewrote the same asset_expression code, so resolving the overlap grew the diff.

What changed since the last review:

• Extended the typing to the partitioned-dag-run responses AIP-76 added (PartitionedDagRunCollectionResponse, PartitionedDagRunDetailResponse), alongside the original DAGDetailsResponse, DAGWithLatestDagRunsResponse, and NextRunAssetsResponse.

• AIP-76 builds the next_run_assets and partitioned responses from a dict via explicit constructors. Since asset_expression is now typed, those routes use model_validate({...}) so pydantic validates the stored dict into the model. This mirrors DAGDetailsResponse.model_validate(dag_model) in routes/public/dags.py and leaves AIP-76's partition logic unchanged.

• Addressed the earlier review: ExpressionType is now derived from the generated client, AssetSummary is removed, and the as ExpressionType casts in AssetProgressCell.tsx and AssetSchedule.tsx are gone. Also removed the now-unused NextRunEvent type.

• Regenerated the OpenAPI spec and TypeScript client.

[Anuragp22]

Ready for maintainer review.

Two commits since the last look:

• Fixed the ruff-format failure on partitioned_dag_runs.py, the only red check.

• Hardened the newly-typed asset_expression field against pre-3.0 migrated rows. The 2.x dataset scheduler stored shapes the 3.0 column rename carried over verbatim: a bare URI string, {"any": [<strings>]}, {"alias": "<name>"}. The typed field would return a 500 on those until the DAG is re-parsed. MaybeAssetExpression now coerces any unrecognized stored shape to null, reproducing the blank render the UI showed while the field was an untyped dict. Added round-trip and coercion tests.

I've addressed all three of bbovenzi's comments on AssetExpression/types.ts.

[Anuragp22]

ready

[potiuk]

@Anuragp22 — the Static checks CI job is failing here, which needs a code fix on your side (a rerun won't clear it). You can reproduce and fix locally with:

pre-commit run --all-files # or: breeze static-checks

Once those pass and CI is green, it'll be ready for a maintainer to pick up. Thanks!

See the PR quality criteria.

_{Automated first-pass triage note drafted by an AI-assisted tool — may get things wrong; once addressed, a real Apache Airflow maintainer takes the next look. (why automated)}

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[pierrejeambrun]

Nice, one suggestion bellow, not blocking

[pierrejeambrun]

Only 1 comments unresolved, then I believe we are good to merge.

[guan404ming]

Besides the unresolved comment, lgtm!

[pierrejeambrun]

LGTM

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 3733e62 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[Anuragp22]

closes: #67692

asset_expression was declared as dict | None on the REST API response models, so the OpenAPI generator emitted { [k: string]: unknown }. The UI compensated by hand-maintaining an ExpressionType discriminated union in src/components/AssetExpression/ and casting the API value through it with no runtime check, so a change to the server shape would not be caught by the TypeScript build. This types the expression on the API side and lets the generated client describe it.

What changed:

• Added a structured AssetExpression model in datamodels/common.py: a recursive discriminated union over the five shapes BaseAsset.as_expression() produces (asset, alias, asset_ref, any, all), following the existing Annotated[Union[...], Discriminator] pattern in that module. Asset leaves carry the id that DagModelOperation.update_dag_asset_expression injects when the expression is persisted. id is optional so a row written before id-enrichment, or migrated from the pre-3.0 dataset format, still validates instead of returning a 500.
• Used the model for every response that serves the field: DAGDetailsResponse, DAGWithLatestDagRunsResponse, and both fields on the partitioned dag run responses.
• Typed the next_run_assets UI endpoint with a new NextRunAssetsResponse model in datamodels/ui/assets.py instead of a bare dict. response_model_exclude_unset=True keeps the response shape identical to before.
• Regenerated the OpenAPI spec and the TypeScript client.
• Removed the hand-maintained ExpressionType union and the casts in AssetProgressCell.tsx and AssetSchedule.tsx; the UI now consumes the generated type. The more precise types also let some now-dead defensive code in AssetExpression.tsx be removed.

For expressions produced by the current code the emitted JSON is unchanged, so this is not a breaking change for API consumers; only the declared schema becomes precise.

Tests: added test_common.py covering round-trip serialization of every variant, the optional id behaviour, and rejection of malformed shapes. Updated the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that as_expression() never produces and that the new model correctly rejects, to the real {"any": [{"asset": {...}}]} shape. The next_run_assets and dag-detail route tests pass unchanged.

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.8), reviewed and verified by the author

---

Important

🛠️ Maintainer triage note for @Anuragp22 · by @potiuk · 2026-06-12 10:47 UTC

Your review threads look addressed — please confirm this PR is ready for maintainer review confirmation.

Feedback from @bbovenzi across 3 unresolved thread(s); you've engaged with each (replies and/or pushes since).

The ball is in your court — you've been assigned to this PR. Reply yes / ready and a maintainer will pick it up from the queue.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[bbovenzi]

Thanks for this one!

Let's rebase and double check our tests. I assume we now need a valid asset_expression in our mocks or make sure our responses can handle None and undefined.

[Anuragp22]

Rebased onto main and fixed the failing tests.

The /dags failures came from the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that BaseAsset.as_expression() never produces. It was accepted while the field was an untyped dict, but the new model correctly rejects the bare leaf. I updated the fixtures to the real {"any": [{"asset": {...}}]} shape. The full api_fastapi suite passes locally.

The force-push is that rebase: I rebased onto current main to clear the merge conflict and squashed the work into a single commit (d88ce26 to 622dc91). No content changed beyond the test fixtures.

[Anuragp22]

Merged main, which now includes AIP-76 (#64571). AIP-76 rewrote the same asset_expression code, so resolving the overlap grew the diff.

What changed since the last review:

• Extended the typing to the partitioned-dag-run responses AIP-76 added (PartitionedDagRunCollectionResponse, PartitionedDagRunDetailResponse), alongside the original DAGDetailsResponse, DAGWithLatestDagRunsResponse, and NextRunAssetsResponse.

• AIP-76 builds the next_run_assets and partitioned responses from a dict via explicit constructors. Since asset_expression is now typed, those routes use model_validate({...}) so pydantic validates the stored dict into the model. This mirrors DAGDetailsResponse.model_validate(dag_model) in routes/public/dags.py and leaves AIP-76's partition logic unchanged.

• Addressed the earlier review: ExpressionType is now derived from the generated client, AssetSummary is removed, and the as ExpressionType casts in AssetProgressCell.tsx and AssetSchedule.tsx are gone. Also removed the now-unused NextRunEvent type.

• Regenerated the OpenAPI spec and TypeScript client.

[Anuragp22]

Ready for maintainer review.

Two commits since the last look:

• Fixed the ruff-format failure on partitioned_dag_runs.py, the only red check.

• Hardened the newly-typed asset_expression field against pre-3.0 migrated rows. The 2.x dataset scheduler stored shapes the 3.0 column rename carried over verbatim: a bare URI string, {"any": [<strings>]}, {"alias": "<name>"}. The typed field would return a 500 on those until the DAG is re-parsed. MaybeAssetExpression now coerces any unrecognized stored shape to null, reproducing the blank render the UI showed while the field was an untyped dict. Added round-trip and coercion tests.

I've addressed all three of bbovenzi's comments on AssetExpression/types.ts.

[Anuragp22]

ready

[potiuk]

@Anuragp22 — the Static checks CI job is failing here, which needs a code fix on your side (a rerun won't clear it). You can reproduce and fix locally with:

pre-commit run --all-files # or: breeze static-checks

Once those pass and CI is green, it'll be ready for a maintainer to pick up. Thanks!

See the PR quality criteria.

_{Automated first-pass triage note drafted by an AI-assisted tool — may get things wrong; once addressed, a real Apache Airflow maintainer takes the next look. (why automated)}

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[pierrejeambrun]

Nice, one suggestion bellow, not blocking

[pierrejeambrun]

Only 1 comments unresolved, then I believe we are good to merge.

[guan404ming]

Besides the unresolved comment, lgtm!

[pierrejeambrun]

LGTM

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 3733e62 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[Anuragp22]

closes: #67692

asset_expression was declared as dict | None on the REST API response models, so the OpenAPI generator emitted { [k: string]: unknown }. The UI compensated by hand-maintaining an ExpressionType discriminated union in src/components/AssetExpression/ and casting the API value through it with no runtime check, so a change to the server shape would not be caught by the TypeScript build. This types the expression on the API side and lets the generated client describe it.

What changed:

• Added a structured AssetExpression model in datamodels/common.py: a recursive discriminated union over the five shapes BaseAsset.as_expression() produces (asset, alias, asset_ref, any, all), following the existing Annotated[Union[...], Discriminator] pattern in that module. Asset leaves carry the id that DagModelOperation.update_dag_asset_expression injects when the expression is persisted. id is optional so a row written before id-enrichment, or migrated from the pre-3.0 dataset format, still validates instead of returning a 500.
• Used the model for every response that serves the field: DAGDetailsResponse, DAGWithLatestDagRunsResponse, and both fields on the partitioned dag run responses.
• Typed the next_run_assets UI endpoint with a new NextRunAssetsResponse model in datamodels/ui/assets.py instead of a bare dict. response_model_exclude_unset=True keeps the response shape identical to before.
• Regenerated the OpenAPI spec and the TypeScript client.
• Removed the hand-maintained ExpressionType union and the casts in AssetProgressCell.tsx and AssetSchedule.tsx; the UI now consumes the generated type. The more precise types also let some now-dead defensive code in AssetExpression.tsx be removed.

For expressions produced by the current code the emitted JSON is unchanged, so this is not a breaking change for API consumers; only the declared schema becomes precise.

Tests: added test_common.py covering round-trip serialization of every variant, the optional id behaviour, and rejection of malformed shapes. Updated the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that as_expression() never produces and that the new model correctly rejects, to the real {"any": [{"asset": {...}}]} shape. The next_run_assets and dag-detail route tests pass unchanged.

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.8), reviewed and verified by the author

---

Important

🛠️ Maintainer triage note for @Anuragp22 · by @potiuk · 2026-06-12 10:47 UTC

Your review threads look addressed — please confirm this PR is ready for maintainer review confirmation.

Feedback from @bbovenzi across 3 unresolved thread(s); you've engaged with each (replies and/or pushes since).

The ball is in your court — you've been assigned to this PR. Reply yes / ready and a maintainer will pick it up from the queue.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[bbovenzi]

Thanks for this one!

Let's rebase and double check our tests. I assume we now need a valid asset_expression in our mocks or make sure our responses can handle None and undefined.

[Anuragp22]

Rebased onto main and fixed the failing tests.

The /dags failures came from the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that BaseAsset.as_expression() never produces. It was accepted while the field was an untyped dict, but the new model correctly rejects the bare leaf. I updated the fixtures to the real {"any": [{"asset": {...}}]} shape. The full api_fastapi suite passes locally.

The force-push is that rebase: I rebased onto current main to clear the merge conflict and squashed the work into a single commit (d88ce26 to 622dc91). No content changed beyond the test fixtures.

[Anuragp22]

Merged main, which now includes AIP-76 (#64571). AIP-76 rewrote the same asset_expression code, so resolving the overlap grew the diff.

What changed since the last review:

• Extended the typing to the partitioned-dag-run responses AIP-76 added (PartitionedDagRunCollectionResponse, PartitionedDagRunDetailResponse), alongside the original DAGDetailsResponse, DAGWithLatestDagRunsResponse, and NextRunAssetsResponse.

• AIP-76 builds the next_run_assets and partitioned responses from a dict via explicit constructors. Since asset_expression is now typed, those routes use model_validate({...}) so pydantic validates the stored dict into the model. This mirrors DAGDetailsResponse.model_validate(dag_model) in routes/public/dags.py and leaves AIP-76's partition logic unchanged.

• Addressed the earlier review: ExpressionType is now derived from the generated client, AssetSummary is removed, and the as ExpressionType casts in AssetProgressCell.tsx and AssetSchedule.tsx are gone. Also removed the now-unused NextRunEvent type.

• Regenerated the OpenAPI spec and TypeScript client.

[Anuragp22]

Ready for maintainer review.

Two commits since the last look:

• Fixed the ruff-format failure on partitioned_dag_runs.py, the only red check.

• Hardened the newly-typed asset_expression field against pre-3.0 migrated rows. The 2.x dataset scheduler stored shapes the 3.0 column rename carried over verbatim: a bare URI string, {"any": [<strings>]}, {"alias": "<name>"}. The typed field would return a 500 on those until the DAG is re-parsed. MaybeAssetExpression now coerces any unrecognized stored shape to null, reproducing the blank render the UI showed while the field was an untyped dict. Added round-trip and coercion tests.

I've addressed all three of bbovenzi's comments on AssetExpression/types.ts.

[Anuragp22]

ready

[potiuk]

@Anuragp22 — the Static checks CI job is failing here, which needs a code fix on your side (a rerun won't clear it). You can reproduce and fix locally with:

pre-commit run --all-files # or: breeze static-checks

Once those pass and CI is green, it'll be ready for a maintainer to pick up. Thanks!

See the PR quality criteria.

_{Automated first-pass triage note drafted by an AI-assisted tool — may get things wrong; once addressed, a real Apache Airflow maintainer takes the next look. (why automated)}

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[pierrejeambrun]

Nice, one suggestion bellow, not blocking

[pierrejeambrun]

Only 1 comments unresolved, then I believe we are good to merge.

[guan404ming]

Besides the unresolved comment, lgtm!

[pierrejeambrun]

LGTM

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 3733e62 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[Anuragp22]

closes: #67692

asset_expression was declared as dict | None on the REST API response models, so the OpenAPI generator emitted { [k: string]: unknown }. The UI compensated by hand-maintaining an ExpressionType discriminated union in src/components/AssetExpression/ and casting the API value through it with no runtime check, so a change to the server shape would not be caught by the TypeScript build. This types the expression on the API side and lets the generated client describe it.

What changed:

• Added a structured AssetExpression model in datamodels/common.py: a recursive discriminated union over the five shapes BaseAsset.as_expression() produces (asset, alias, asset_ref, any, all), following the existing Annotated[Union[...], Discriminator] pattern in that module. Asset leaves carry the id that DagModelOperation.update_dag_asset_expression injects when the expression is persisted. id is optional so a row written before id-enrichment, or migrated from the pre-3.0 dataset format, still validates instead of returning a 500.
• Used the model for every response that serves the field: DAGDetailsResponse, DAGWithLatestDagRunsResponse, and both fields on the partitioned dag run responses.
• Typed the next_run_assets UI endpoint with a new NextRunAssetsResponse model in datamodels/ui/assets.py instead of a bare dict. response_model_exclude_unset=True keeps the response shape identical to before.
• Regenerated the OpenAPI spec and the TypeScript client.
• Removed the hand-maintained ExpressionType union and the casts in AssetProgressCell.tsx and AssetSchedule.tsx; the UI now consumes the generated type. The more precise types also let some now-dead defensive code in AssetExpression.tsx be removed.

For expressions produced by the current code the emitted JSON is unchanged, so this is not a breaking change for API consumers; only the declared schema becomes precise.

Tests: added test_common.py covering round-trip serialization of every variant, the optional id behaviour, and rejection of malformed shapes. Updated the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that as_expression() never produces and that the new model correctly rejects, to the real {"any": [{"asset": {...}}]} shape. The next_run_assets and dag-detail route tests pass unchanged.

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.8), reviewed and verified by the author

---

Important

🛠️ Maintainer triage note for @Anuragp22 · by @potiuk · 2026-06-12 10:47 UTC

Your review threads look addressed — please confirm this PR is ready for maintainer review confirmation.

Feedback from @bbovenzi across 3 unresolved thread(s); you've engaged with each (replies and/or pushes since).

The ball is in your court — you've been assigned to this PR. Reply yes / ready and a maintainer will pick it up from the queue.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[bbovenzi]

Thanks for this one!

Let's rebase and double check our tests. I assume we now need a valid asset_expression in our mocks or make sure our responses can handle None and undefined.

[Anuragp22]

Rebased onto main and fixed the failing tests.

The /dags failures came from the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that BaseAsset.as_expression() never produces. It was accepted while the field was an untyped dict, but the new model correctly rejects the bare leaf. I updated the fixtures to the real {"any": [{"asset": {...}}]} shape. The full api_fastapi suite passes locally.

The force-push is that rebase: I rebased onto current main to clear the merge conflict and squashed the work into a single commit (d88ce26 to 622dc91). No content changed beyond the test fixtures.

[Anuragp22]

Merged main, which now includes AIP-76 (#64571). AIP-76 rewrote the same asset_expression code, so resolving the overlap grew the diff.

What changed since the last review:

• Extended the typing to the partitioned-dag-run responses AIP-76 added (PartitionedDagRunCollectionResponse, PartitionedDagRunDetailResponse), alongside the original DAGDetailsResponse, DAGWithLatestDagRunsResponse, and NextRunAssetsResponse.

• AIP-76 builds the next_run_assets and partitioned responses from a dict via explicit constructors. Since asset_expression is now typed, those routes use model_validate({...}) so pydantic validates the stored dict into the model. This mirrors DAGDetailsResponse.model_validate(dag_model) in routes/public/dags.py and leaves AIP-76's partition logic unchanged.

• Addressed the earlier review: ExpressionType is now derived from the generated client, AssetSummary is removed, and the as ExpressionType casts in AssetProgressCell.tsx and AssetSchedule.tsx are gone. Also removed the now-unused NextRunEvent type.

• Regenerated the OpenAPI spec and TypeScript client.

[Anuragp22]

Ready for maintainer review.

Two commits since the last look:

• Fixed the ruff-format failure on partitioned_dag_runs.py, the only red check.

• Hardened the newly-typed asset_expression field against pre-3.0 migrated rows. The 2.x dataset scheduler stored shapes the 3.0 column rename carried over verbatim: a bare URI string, {"any": [<strings>]}, {"alias": "<name>"}. The typed field would return a 500 on those until the DAG is re-parsed. MaybeAssetExpression now coerces any unrecognized stored shape to null, reproducing the blank render the UI showed while the field was an untyped dict. Added round-trip and coercion tests.

I've addressed all three of bbovenzi's comments on AssetExpression/types.ts.

[Anuragp22]

ready

[potiuk]

@Anuragp22 — the Static checks CI job is failing here, which needs a code fix on your side (a rerun won't clear it). You can reproduce and fix locally with:

pre-commit run --all-files # or: breeze static-checks

Once those pass and CI is green, it'll be ready for a maintainer to pick up. Thanks!

See the PR quality criteria.

_{Automated first-pass triage note drafted by an AI-assisted tool — may get things wrong; once addressed, a real Apache Airflow maintainer takes the next look. (why automated)}

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[pierrejeambrun]

Nice, one suggestion bellow, not blocking

[pierrejeambrun]

Only 1 comments unresolved, then I believe we are good to merge.

[guan404ming]

Besides the unresolved comment, lgtm!

[pierrejeambrun]

LGTM

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 3733e62 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[Anuragp22]

closes: #67692

asset_expression was declared as dict | None on the REST API response models, so the OpenAPI generator emitted { [k: string]: unknown }. The UI compensated by hand-maintaining an ExpressionType discriminated union in src/components/AssetExpression/ and casting the API value through it with no runtime check, so a change to the server shape would not be caught by the TypeScript build. This types the expression on the API side and lets the generated client describe it.

What changed:

• Added a structured AssetExpression model in datamodels/common.py: a recursive discriminated union over the five shapes BaseAsset.as_expression() produces (asset, alias, asset_ref, any, all), following the existing Annotated[Union[...], Discriminator] pattern in that module. Asset leaves carry the id that DagModelOperation.update_dag_asset_expression injects when the expression is persisted. id is optional so a row written before id-enrichment, or migrated from the pre-3.0 dataset format, still validates instead of returning a 500.
• Used the model for every response that serves the field: DAGDetailsResponse, DAGWithLatestDagRunsResponse, and both fields on the partitioned dag run responses.
• Typed the next_run_assets UI endpoint with a new NextRunAssetsResponse model in datamodels/ui/assets.py instead of a bare dict. response_model_exclude_unset=True keeps the response shape identical to before.
• Regenerated the OpenAPI spec and the TypeScript client.
• Removed the hand-maintained ExpressionType union and the casts in AssetProgressCell.tsx and AssetSchedule.tsx; the UI now consumes the generated type. The more precise types also let some now-dead defensive code in AssetExpression.tsx be removed.

For expressions produced by the current code the emitted JSON is unchanged, so this is not a breaking change for API consumers; only the declared schema becomes precise.

Tests: added test_common.py covering round-trip serialization of every variant, the optional id behaviour, and rejection of malformed shapes. Updated the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that as_expression() never produces and that the new model correctly rejects, to the real {"any": [{"asset": {...}}]} shape. The next_run_assets and dag-detail route tests pass unchanged.

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.8), reviewed and verified by the author

---

Important

🛠️ Maintainer triage note for @Anuragp22 · by @potiuk · 2026-06-12 10:47 UTC

Your review threads look addressed — please confirm this PR is ready for maintainer review confirmation.

Feedback from @bbovenzi across 3 unresolved thread(s); you've engaged with each (replies and/or pushes since).

The ball is in your court — you've been assigned to this PR. Reply yes / ready and a maintainer will pick it up from the queue.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[bbovenzi]

Thanks for this one!

Let's rebase and double check our tests. I assume we now need a valid asset_expression in our mocks or make sure our responses can handle None and undefined.

[Anuragp22]

Rebased onto main and fixed the failing tests.

The /dags failures came from the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that BaseAsset.as_expression() never produces. It was accepted while the field was an untyped dict, but the new model correctly rejects the bare leaf. I updated the fixtures to the real {"any": [{"asset": {...}}]} shape. The full api_fastapi suite passes locally.

The force-push is that rebase: I rebased onto current main to clear the merge conflict and squashed the work into a single commit (d88ce26 to 622dc91). No content changed beyond the test fixtures.

[Anuragp22]

Merged main, which now includes AIP-76 (#64571). AIP-76 rewrote the same asset_expression code, so resolving the overlap grew the diff.

What changed since the last review:

• Extended the typing to the partitioned-dag-run responses AIP-76 added (PartitionedDagRunCollectionResponse, PartitionedDagRunDetailResponse), alongside the original DAGDetailsResponse, DAGWithLatestDagRunsResponse, and NextRunAssetsResponse.

• AIP-76 builds the next_run_assets and partitioned responses from a dict via explicit constructors. Since asset_expression is now typed, those routes use model_validate({...}) so pydantic validates the stored dict into the model. This mirrors DAGDetailsResponse.model_validate(dag_model) in routes/public/dags.py and leaves AIP-76's partition logic unchanged.

• Addressed the earlier review: ExpressionType is now derived from the generated client, AssetSummary is removed, and the as ExpressionType casts in AssetProgressCell.tsx and AssetSchedule.tsx are gone. Also removed the now-unused NextRunEvent type.

• Regenerated the OpenAPI spec and TypeScript client.

[Anuragp22]

Ready for maintainer review.

Two commits since the last look:

• Fixed the ruff-format failure on partitioned_dag_runs.py, the only red check.

• Hardened the newly-typed asset_expression field against pre-3.0 migrated rows. The 2.x dataset scheduler stored shapes the 3.0 column rename carried over verbatim: a bare URI string, {"any": [<strings>]}, {"alias": "<name>"}. The typed field would return a 500 on those until the DAG is re-parsed. MaybeAssetExpression now coerces any unrecognized stored shape to null, reproducing the blank render the UI showed while the field was an untyped dict. Added round-trip and coercion tests.

I've addressed all three of bbovenzi's comments on AssetExpression/types.ts.

[Anuragp22]

ready

[potiuk]

@Anuragp22 — the Static checks CI job is failing here, which needs a code fix on your side (a rerun won't clear it). You can reproduce and fix locally with:

pre-commit run --all-files # or: breeze static-checks

Once those pass and CI is green, it'll be ready for a maintainer to pick up. Thanks!

See the PR quality criteria.

_{Automated first-pass triage note drafted by an AI-assisted tool — may get things wrong; once addressed, a real Apache Airflow maintainer takes the next look. (why automated)}

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[pierrejeambrun]

Nice, one suggestion bellow, not blocking

[pierrejeambrun]

Only 1 comments unresolved, then I believe we are good to merge.

[guan404ming]

Besides the unresolved comment, lgtm!

[pierrejeambrun]

LGTM

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 3733e62 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[Anuragp22]

closes: #67692

asset_expression was declared as dict | None on the REST API response models, so the OpenAPI generator emitted { [k: string]: unknown }. The UI compensated by hand-maintaining an ExpressionType discriminated union in src/components/AssetExpression/ and casting the API value through it with no runtime check, so a change to the server shape would not be caught by the TypeScript build. This types the expression on the API side and lets the generated client describe it.

What changed:

• Added a structured AssetExpression model in datamodels/common.py: a recursive discriminated union over the five shapes BaseAsset.as_expression() produces (asset, alias, asset_ref, any, all), following the existing Annotated[Union[...], Discriminator] pattern in that module. Asset leaves carry the id that DagModelOperation.update_dag_asset_expression injects when the expression is persisted. id is optional so a row written before id-enrichment, or migrated from the pre-3.0 dataset format, still validates instead of returning a 500.
• Used the model for every response that serves the field: DAGDetailsResponse, DAGWithLatestDagRunsResponse, and both fields on the partitioned dag run responses.
• Typed the next_run_assets UI endpoint with a new NextRunAssetsResponse model in datamodels/ui/assets.py instead of a bare dict. response_model_exclude_unset=True keeps the response shape identical to before.
• Regenerated the OpenAPI spec and the TypeScript client.
• Removed the hand-maintained ExpressionType union and the casts in AssetProgressCell.tsx and AssetSchedule.tsx; the UI now consumes the generated type. The more precise types also let some now-dead defensive code in AssetExpression.tsx be removed.

For expressions produced by the current code the emitted JSON is unchanged, so this is not a breaking change for API consumers; only the declared schema becomes precise.

Tests: added test_common.py covering round-trip serialization of every variant, the optional id behaviour, and rejection of malformed shapes. Updated the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that as_expression() never produces and that the new model correctly rejects, to the real {"any": [{"asset": {...}}]} shape. The next_run_assets and dag-detail route tests pass unchanged.

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 4.8), reviewed and verified by the author

---

Important

🛠️ Maintainer triage note for @Anuragp22 · by @potiuk · 2026-06-12 10:47 UTC

Your review threads look addressed — please confirm this PR is ready for maintainer review confirmation.

Feedback from @bbovenzi across 3 unresolved thread(s); you've engaged with each (replies and/or pushes since).

The ball is in your court — you've been assigned to this PR. Reply yes / ready and a maintainer will pick it up from the queue.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[bbovenzi]

Thanks for this one!

Let's rebase and double check our tests. I assume we now need a valid asset_expression in our mocks or make sure our responses can handle None and undefined.

[Anuragp22]

Rebased onto main and fixed the failing tests.

The /dags failures came from the test_get_dags fixtures, which set asset_expression to a simplified {"any": [{"uri": ...}]} shape that BaseAsset.as_expression() never produces. It was accepted while the field was an untyped dict, but the new model correctly rejects the bare leaf. I updated the fixtures to the real {"any": [{"asset": {...}}]} shape. The full api_fastapi suite passes locally.

The force-push is that rebase: I rebased onto current main to clear the merge conflict and squashed the work into a single commit (d88ce26 to 622dc91). No content changed beyond the test fixtures.

[Anuragp22]

Merged main, which now includes AIP-76 (#64571). AIP-76 rewrote the same asset_expression code, so resolving the overlap grew the diff.

What changed since the last review:

• Extended the typing to the partitioned-dag-run responses AIP-76 added (PartitionedDagRunCollectionResponse, PartitionedDagRunDetailResponse), alongside the original DAGDetailsResponse, DAGWithLatestDagRunsResponse, and NextRunAssetsResponse.

• AIP-76 builds the next_run_assets and partitioned responses from a dict via explicit constructors. Since asset_expression is now typed, those routes use model_validate({...}) so pydantic validates the stored dict into the model. This mirrors DAGDetailsResponse.model_validate(dag_model) in routes/public/dags.py and leaves AIP-76's partition logic unchanged.

• Addressed the earlier review: ExpressionType is now derived from the generated client, AssetSummary is removed, and the as ExpressionType casts in AssetProgressCell.tsx and AssetSchedule.tsx are gone. Also removed the now-unused NextRunEvent type.

• Regenerated the OpenAPI spec and TypeScript client.

[Anuragp22]

Ready for maintainer review.

Two commits since the last look:

• Fixed the ruff-format failure on partitioned_dag_runs.py, the only red check.

• Hardened the newly-typed asset_expression field against pre-3.0 migrated rows. The 2.x dataset scheduler stored shapes the 3.0 column rename carried over verbatim: a bare URI string, {"any": [<strings>]}, {"alias": "<name>"}. The typed field would return a 500 on those until the DAG is re-parsed. MaybeAssetExpression now coerces any unrecognized stored shape to null, reproducing the blank render the UI showed while the field was an untyped dict. Added round-trip and coercion tests.

I've addressed all three of bbovenzi's comments on AssetExpression/types.ts.

[Anuragp22]

ready

[potiuk]

@Anuragp22 — the Static checks CI job is failing here, which needs a code fix on your side (a rerun won't clear it). You can reproduce and fix locally with:

pre-commit run --all-files # or: breeze static-checks

Once those pass and CI is green, it'll be ready for a maintainer to pick up. Thanks!

See the PR quality criteria.

_{Automated first-pass triage note drafted by an AI-assisted tool — may get things wrong; once addressed, a real Apache Airflow maintainer takes the next look. (why automated)}

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @potiuk before posting

[pierrejeambrun]

Nice, one suggestion bellow, not blocking

[pierrejeambrun]

Only 1 comments unresolved, then I believe we are good to merge.

[guan404ming]

Besides the unresolved comment, lgtm!

[pierrejeambrun]

LGTM

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 3733e62 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.