Breaking Change Caused by Fastapi Update
Upon updating fastapi to version 0.109.2 the current method for encoding UTCDateTime values as a custom type for pydantic became deprecated. This was originally handled in the script pydantic_utcdatetime.py.
Upon further investigation, @erigler discovered that recent versions of fastapi attempted to be compatible with both version 1 and 2 of pydantic (we currently use pydantic version 1), by introducing their method of custom serialization to deal with certain unrecognizable values like UTCDateTime objects. So, when pydantic_utcdatetime.py adds a custom type to the pydantic.json.ENCODERS_BY_TYPE dictionary, it no longer gets used by fastapi. The updates to the fastapi source code can be found here
I added a simple workaround in pydantic_utcdatetime.py to convert the UTCDatetime object back to a string format from the nanosecond representation provided by fastapi.
Other solutions proposed by @erigler are:
- Modify pydantic_utcdatetime.py so that it modifies fastapi.encoders.ENCODERS_BY_TYPE instead of pydantic.json.ENCODERS_BY_TYPE. However, this only fixes fastapi, and does nothing for pydantic models in general. Maybe this doesn't matter for our needs, but the name pydantic_utcdatetime.py suddenly seems a little misleading.
- Update geomag-algorithms to require pydantic v2, and change the way we customize serialization to use pydantic's new recommended tools. I don' t yet understand how to do this, but it is supposed to be easier and more robust (https://github.com/pydantic/pydantic/blob/main/docs/concepts/serialization.md#custom-serializers).
@awernle @bgeels Tagging both of you in this so everyone can be apart of the discussion and propose any solutions they see fit.