steveahnahn opened a new pull request, #71862:
URL: https://github.com/apache/airflow/pull/71862
`inlet_events` fails on any released Task SDK when an asset event created a
Dag run that has not started yet. The worker raises:
```
pydantic_core.ValidationError: 1 validation error for AssetEventsResponse
asset_events.0.created_dagruns.0.start_date
Input should be a valid datetime [type=datetime_type, input_value=None]
```
### Root cause
#71379 changed `DagRunAssetReference.start_date` to `datetime | None` in the
Execution API, which is correct at head: a queued or cleared Dag run genuinely
has no start date, and returning one was the 500 reported in #71360.
That PR touched no file under `execution_api/versions/`, so no
`VersionChange` pins the old type. Cadwyn regenerates the response model for
every older version from head, so those versions inherited the nullability too,
and the server now serialises `start_date: null` at every negotiated version.
Every released Task SDK declares the field non-nullable with `extra="forbid"`,
so `AssetEventsResponse.model_validate_json` rejects the whole response and the
task fails.
The newest released Task SDK (1.3.0) pins API version `2026-06-30` and is
affected.
### Fix
`MakeAssetEventDagRunStartDateNullable` pins the old non-null type for
previous versions and backfills the value, following
`MakeDagRunStartDateNullable` which handled the same change for `DagRun`.
Converters only see the response body, so the fallback value has to be in
the body. Every other datetime on this model is nullable, so the change adds
`run_after` — always set on a Dag run — and the same `VersionChange` hides it
from older versions. Head clients see the real `start_date` unchanged,
including `null`.
The change registers into the existing `2026-10-30` version rather than a
new one, because no released SDK negotiates `2026-10-30` yet: 1.3.0 pins
`2026-06-30`. Clients of `2026-06-30` and older get the migrated shape.
### Verification
The regression test asserts the response is non-null at `2026-06-30`. Beyond
that, the released client model was extracted from the `task-sdk/1.3.0` tag and
used to validate the actual response body: it rejects the current output and
accepts it after this change.
Generated artifacts (`_generated.py`, `schema.json`, `supervisor.ts`) were
regenerated by their hooks, not edited by hand.
related: #71379
related: #71360
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Opus 5)
Generated-by: Claude Code (Opus 5) following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
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]
