Do not require dag_version_id in workload TI model

[ephraimbuddy]

Older TIs won't have the dag_version_id, so we shouldn't require it in workload's TI model.

closes: #55713

[o-nikolas]

Looks like API spec needs some updating, also should we have some tests added or at least updated to test this edgecase?

[ephraimbuddy]

Looks like API spec needs some updating, also should we have some tests added or at least updated to test this edgecase?

Thanks, updated

[ashb]

How can we execute a TI without a dag version? For it to be executed, doesn't it have to still exist, and this get reparsed to include a dag version?

[ephraimbuddy]

We can execute a TI without a dag_version since the RuntimeTaskInstance model doesn't include the dag_version_id:

airflow/task-sdk/src/airflow/sdk/execution_time/task_runner.py

Line 129 in 9bc58a2

class RuntimeTaskInstance(TaskInstance):

. I hope my understanding is correct? Main purpose of the dag_version_id is for display not for execution

[ashb]

Isn't that dag_version_id the one that the (git, etc) dag bundle backend is told to checkout?

[ashb]

Ah no, bundle_info is what the dag bundle info is.

I still wonder how it's actually possible to get to an executor with no dag_version set?

[ephraimbuddy]

No. dag bundle backend checks out dag bundle version:

airflow/airflow-core/src/airflow/models/dagbundle.py

Line 47 in 9bc58a2

version = Column(String(200), nullable=True)

[ephraimbuddy]

And it's more about the dagrun than task instance

[ashb]

Still -- aren't "all" DagRuns in airflow 3 meant to have a version? What is the case by which we end up without a dag version but the task in the executor?

[ephraimbuddy]

I will experiment with this by reproducing this with a running TI

[ephraimbuddy]

Alternative to this that's less disruptive: #55884

[ephraimbuddy]

Closing as the alternative has been merged