AIP-84 Fix: Allow Null Values for end_date Field in Dashboard Endpint in FastAPI

[bugraoz93]

related: #43846

• Allow safe_date_time to return None if the input is None
• Handle None in queries/endpoints
• Simplify unit tests

I have created a separate PR because write permissions don't allow me to push to the existing PR.
cc: @bbovenzi @pierrejeambrun @tirkarthi

---

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

[pierrejeambrun]

Thanks a few suggestions

[tirkarthi]

The following were added in #43934 . The changes broke dashboard endpoint probably due str changed to datetime . During resolving merge conflicts maybe OptionalDateTimeQuery could be used for end_date which hopefully resolves this PR's use case.

DateTimeQuery = Annotated[datetime, AfterValidator(_safe_parse_datetime)]
OptionalDateTimeQuery = Annotated[Union[datetime, None], AfterValidator(_safe_parse_datetime_optional)]

https://github.com/apache/airflow/pull/43934/files#diff-183a76763667e545ddd8c2aadf6858fdd7a80fecdd04b71e61eaa4ff344239cdR638-R639

[bugraoz93]

Thanks a few suggestions

I’ve made the adjustments in the methods and let FastAPI handle it as a 422. I followed a similar approach to the changes you made in the other PR.

The following were added in #43934 . The changes broke dashboard endpoint probably due str changed to datetime . During resolving merge conflicts maybe OptionalDateTimeQuery could be used for end_date which hopefully resolves this PR's use case.

DateTimeQuery = Annotated[datetime, AfterValidator(_safe_parse_datetime)]
OptionalDateTimeQuery = Annotated[Union[datetime, None], AfterValidator(_safe_parse_datetime_optional)]

https://github.com/apache/airflow/pull/43934/files#diff-183a76763667e545ddd8c2aadf6858fdd7a80fecdd04b71e61eaa4ff344239cdR638-R639

I haven’t updated the annotation to datetime yet because, in airflow/utils/timezone.py, we’re parsing the date as a pendulum object to ensure consistent timezone handling, and it currently accepts a string. If we want to validate the datetime type directly in FastAPI and ensure it works with pendulum for proper timezone handling, we could introduce a new implementation using something like pendulum.instance(). However, I’m uncertain if adding that new capability is necessary. If it is, I am up for the change.

[bugraoz93]

FastAPI itself returns str for datetime objects in both requests and responses. As mentioned earlier, I’m not certain if there would be a meaningful difference since pendulum.parse() already supports the ISO 8601 format.

• datetime.datetime:
  A Python datetime.datetime.
  In requests and responses will be represented as a str in ISO 8601 format, like: 2008-09-15T15:53:00+05:00.

https://fastapi.tiangolo.com/tutorial/extra-data-types/?h=datet#other-data-types

[pierrejeambrun]

Looks good, let us just merge again the PR introducing OptionalDateTimeQuery (it got reverted because of CI issues not catching tests etc...) and we should be good to go

[bugraoz93]

Looks good, let us just merge again the PR introducing OptionalDateTimeQuery (it got reverted because of CI issues not catching tests etc...) and we should be good to go

Thanks for the quick reviews and for merging the changes again so promptly! I aimed to replicate the changes and test the endpoint accordingly. I also followed up on the CI failure, which helped me realize I needed to apply a similar fix to the CI script updates in another PR later on :)

[pierrejeambrun]

Restarting failed job, ready to merge when CI is green.