Inconsistent optional point ID type in scroll response

Why is returned point ID for scroll an Option? Is it safe to unwrap?

Python client type does not have None variant:
https://github.com/qdrant/qdrant-client/blob/981117a506b549e9dcd51cd633d4a6162df3b05f/qdrant_client/async_qdrant_client.py#L1371
->
https://github.com/qdrant/qdrant-client/blob/981117a506b549e9dcd51cd633d4a6162df3b05f/qdrant_client/conversions/common_types.py#L96
->
https://github.com/qdrant/qdrant-client/blob/981117a506b549e9dcd51cd633d4a6162df3b05f/qdrant_client/http/models/models.py#L2219
->
https://github.com/qdrant/qdrant-client/blob/981117a506b549e9dcd51cd633d4a6162df3b05f/qdrant_client/http/models/models.py#L3472-L3475

ExtendedPointId = Union[
    StrictInt,
    StrictStr,
]

Meanwhile rust:
https://github.com/qdrant/rust-client/blob/9feb73ee7289c11d9bf0db8cf369e680d48d0643/src/qdrant_client/points.rs#L227

The next parts are autogenerated i think

    #[prost(message, repeated, tag = "2")]
    pub result: ::prost::alloc::vec::Vec<RetrievedPoint>,

pub struct RetrievedPoint {
    #[prost(message, optional, tag = "1")]
    pub id: ::core::option::Option<PointId>,

Start with src/qdrant_client/points.rs at the RetrievedPoint definition and compare its optional PointId field with the linked Python client models and scroll response types. Check whether the generated Rust type reflects the API contract and whether unwrapping is safe. Done means the optional-ID behavior is resolved and the Rust and Python client representations are consistent or clearly documented.