fix(serialized_objects): try to infer data interval if it's none

[Lee-W]

Why

TLDR: fix serialization for pre AIP-39 dag run history

The discussion in

airflow/airflow-core/src/airflow/serialization/serialized_objects.py

Lines 2170 to 2173 in d2c9563

	# the older implementation has call to infer_automated_data_interval if data_interval is None, do we want to keep that or raise
	# an exception?
	if data_interval is None:
	raise ValueError(f"Cannot calculate data interval for run {run}")

about LazyDeserializedDAG.get_run_data_interval raises the question of whether we should use infer_automated_data_interval when data_interval is None. After testing, I believe this is necessary to avoid forcing users to purge their pre-AIP-39 history.

Per

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

Lines 538 to 540 in d2c9563

	# Compatibility: runs created before AIP-39 implementation don't have an
	# explicit data interval. Try to infer from the logical date.
	return self.infer_automated_data_interval(run.logical_date)

, this is still managed in the dag model. However, instead of calling infer_automated_data_interval for custom intervals, comments suggest we shouldn't modify this function as stated #32074, but rather call timetable.infer_manual_data_interval(run_after=logical_date) which is extended and fixed in #32118.

What

Fallback to timetable.infer_manual_data_interval(run_after=logical_date) if data_interval is None when deserialize a dag

---

^ 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.

[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 4f26e45 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