Inconsistent optional point ID type in scroll response

[Fogapod]

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:

rust-client/src/qdrant_client/points.rs

Line 227 in 9feb73e

pub async fn scroll(&self, request: impl Into<ScrollPoints>) -> QdrantResult<ScrollResponse> {

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>,

[timvisee]

Yes, it is safe to unwrap. A point always has a point ID.

It is an (internal) limitation of the generated gRPC client. It internally makes all fields optional.

In Python we have a wrapper around it that gets rid of the option. In Rust we currently do not. Sorry for the inconvenience.