Fix dag_versions property when created_dag_version is None with bundle_version set

[vatsrahul1001]

This PR address issue when we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

This caused the dag_versions property to return [None] instead of an empty list:

ifself.bundle_version:
return [self.created_dag_version] # Returns [None] when created_dag_version is None

When Pydantic tries to serialize [None], it fails validation because it expects DagVersion objects.
Modified the dag_versions property to handle None values gracefully:

# Before return [self.created_dag_version]
# After (fixed)return [self.created_dag_version] ifself.created_dag_versionisnotNoneelse []

Result:

• Before: API returns 500 error with ValidationError
• After: API returns 200 with "dag_versions": []

Testing

• Added a test test_dag_run_dag_versions_with_null_created_dag_version covers this exact scenario
• Manually reproduced issue and verified fix resolves the error.

closes: #52660

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jedcunningham]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

[vatsrahul1001]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

Ideally, this should not have happened as bundle_version and created_dag_version_id are both set as null if runs are migrated from 2.x. I noticed this behaviour in one of our env where we were getting this error.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 79e6fd3 v3-0-test

This should apply the commit to the v3-0-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

[vatsrahul1001]

Manual backport: #54010

[vatsrahul1001]

This PR address issue when we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

This caused the dag_versions property to return [None] instead of an empty list:

ifself.bundle_version:
return [self.created_dag_version] # Returns [None] when created_dag_version is None

When Pydantic tries to serialize [None], it fails validation because it expects DagVersion objects.
Modified the dag_versions property to handle None values gracefully:

# Before return [self.created_dag_version]
# After (fixed)return [self.created_dag_version] ifself.created_dag_versionisnotNoneelse []

Result:

• Before: API returns 500 error with ValidationError
• After: API returns 200 with "dag_versions": []

Testing

• Added a test test_dag_run_dag_versions_with_null_created_dag_version covers this exact scenario
• Manually reproduced issue and verified fix resolves the error.

closes: #52660

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jedcunningham]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

[vatsrahul1001]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

Ideally, this should not have happened as bundle_version and created_dag_version_id are both set as null if runs are migrated from 2.x. I noticed this behaviour in one of our env where we were getting this error.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 79e6fd3 v3-0-test

This should apply the commit to the v3-0-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

[vatsrahul1001]

Manual backport: #54010

[vatsrahul1001]

This PR address issue when we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

This caused the dag_versions property to return [None] instead of an empty list:

ifself.bundle_version:
return [self.created_dag_version] # Returns [None] when created_dag_version is None

When Pydantic tries to serialize [None], it fails validation because it expects DagVersion objects.
Modified the dag_versions property to handle None values gracefully:

# Before return [self.created_dag_version]
# After (fixed)return [self.created_dag_version] ifself.created_dag_versionisnotNoneelse []

Result:

• Before: API returns 500 error with ValidationError
• After: API returns 200 with "dag_versions": []

Testing

• Added a test test_dag_run_dag_versions_with_null_created_dag_version covers this exact scenario
• Manually reproduced issue and verified fix resolves the error.

closes: #52660

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jedcunningham]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

[vatsrahul1001]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

Ideally, this should not have happened as bundle_version and created_dag_version_id are both set as null if runs are migrated from 2.x. I noticed this behaviour in one of our env where we were getting this error.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 79e6fd3 v3-0-test

This should apply the commit to the v3-0-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

[vatsrahul1001]

Manual backport: #54010

[vatsrahul1001]

This PR address issue when we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

This caused the dag_versions property to return [None] instead of an empty list:

ifself.bundle_version:
return [self.created_dag_version] # Returns [None] when created_dag_version is None

When Pydantic tries to serialize [None], it fails validation because it expects DagVersion objects.
Modified the dag_versions property to handle None values gracefully:

# Before return [self.created_dag_version]
# After (fixed)return [self.created_dag_version] ifself.created_dag_versionisnotNoneelse []

Result:

• Before: API returns 500 error with ValidationError
• After: API returns 200 with "dag_versions": []

Testing

• Added a test test_dag_run_dag_versions_with_null_created_dag_version covers this exact scenario
• Manually reproduced issue and verified fix resolves the error.

closes: #52660

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jedcunningham]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

[vatsrahul1001]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

Ideally, this should not have happened as bundle_version and created_dag_version_id are both set as null if runs are migrated from 2.x. I noticed this behaviour in one of our env where we were getting this error.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 79e6fd3 v3-0-test

This should apply the commit to the v3-0-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

[vatsrahul1001]

Manual backport: #54010

[vatsrahul1001]

This PR address issue when we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

This caused the dag_versions property to return [None] instead of an empty list:

ifself.bundle_version:
return [self.created_dag_version] # Returns [None] when created_dag_version is None

When Pydantic tries to serialize [None], it fails validation because it expects DagVersion objects.
Modified the dag_versions property to handle None values gracefully:

# Before return [self.created_dag_version]
# After (fixed)return [self.created_dag_version] ifself.created_dag_versionisnotNoneelse []

Result:

• Before: API returns 500 error with ValidationError
• After: API returns 200 with "dag_versions": []

Testing

• Added a test test_dag_run_dag_versions_with_null_created_dag_version covers this exact scenario
• Manually reproduced issue and verified fix resolves the error.

closes: #52660

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jedcunningham]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

[vatsrahul1001]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

Ideally, this should not have happened as bundle_version and created_dag_version_id are both set as null if runs are migrated from 2.x. I noticed this behaviour in one of our env where we were getting this error.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 79e6fd3 v3-0-test

This should apply the commit to the v3-0-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

[vatsrahul1001]

Manual backport: #54010

[vatsrahul1001]

This PR address issue when we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

This caused the dag_versions property to return [None] instead of an empty list:

ifself.bundle_version:
return [self.created_dag_version] # Returns [None] when created_dag_version is None

When Pydantic tries to serialize [None], it fails validation because it expects DagVersion objects.
Modified the dag_versions property to handle None values gracefully:

# Before return [self.created_dag_version]
# After (fixed)return [self.created_dag_version] ifself.created_dag_versionisnotNoneelse []

Result:

• Before: API returns 500 error with ValidationError
• After: API returns 200 with "dag_versions": []

Testing

• Added a test test_dag_run_dag_versions_with_null_created_dag_version covers this exact scenario
• Manually reproduced issue and verified fix resolves the error.

closes: #52660

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jedcunningham]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

[vatsrahul1001]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

Ideally, this should not have happened as bundle_version and created_dag_version_id are both set as null if runs are migrated from 2.x. I noticed this behaviour in one of our env where we were getting this error.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 79e6fd3 v3-0-test

This should apply the commit to the v3-0-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

[vatsrahul1001]

Manual backport: #54010

[vatsrahul1001]

This PR address issue when we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

This caused the dag_versions property to return [None] instead of an empty list:

ifself.bundle_version:
return [self.created_dag_version] # Returns [None] when created_dag_version is None

When Pydantic tries to serialize [None], it fails validation because it expects DagVersion objects.
Modified the dag_versions property to handle None values gracefully:

# Before return [self.created_dag_version]
# After (fixed)return [self.created_dag_version] ifself.created_dag_versionisnotNoneelse []

Result:

• Before: API returns 500 error with ValidationError
• After: API returns 200 with "dag_versions": []

Testing

• Added a test test_dag_run_dag_versions_with_null_created_dag_version covers this exact scenario
• Manually reproduced issue and verified fix resolves the error.

closes: #52660

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jedcunningham]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

[vatsrahul1001]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

Ideally, this should not have happened as bundle_version and created_dag_version_id are both set as null if runs are migrated from 2.x. I noticed this behaviour in one of our env where we were getting this error.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 79e6fd3 v3-0-test

This should apply the commit to the v3-0-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

[vatsrahul1001]

Manual backport: #54010

[vatsrahul1001]

This PR address issue when we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

This caused the dag_versions property to return [None] instead of an empty list:

ifself.bundle_version:
return [self.created_dag_version] # Returns [None] when created_dag_version is None

When Pydantic tries to serialize [None], it fails validation because it expects DagVersion objects.
Modified the dag_versions property to handle None values gracefully:

# Before return [self.created_dag_version]
# After (fixed)return [self.created_dag_version] ifself.created_dag_versionisnotNoneelse []

Result:

• Before: API returns 500 error with ValidationError
• After: API returns 200 with "dag_versions": []

Testing

• Added a test test_dag_run_dag_versions_with_null_created_dag_version covers this exact scenario
• Manually reproduced issue and verified fix resolves the error.

closes: #52660

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[jedcunningham]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

[vatsrahul1001]

we have some run from Airflow2.x which have bundle_version ≠ NULL (Git bundle deployment configured) and created_dag_version_id created_dag_version_id = NULL (no dag version assigned during creation)

How does this happen?

Ideally, this should not have happened as bundle_version and created_dag_version_id are both set as null if runs are migrated from 2.x. I noticed this behaviour in one of our env where we were getting this error.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 79e6fd3 v3-0-test

This should apply the commit to the v3-0-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

[vatsrahul1001]

Manual backport: #54010