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.

[Strawbang]

Hi, I'd like to take a stab at this one.

I've been using the Rust client in a project and keep running into the Option thing you always end up unwrapping it anyway, which feels weird when you know it's always there.

I was thinking of adding proper wrapper structs with a guaranteed id: PointId, similar to what the Python client does, plus From impls to convert from the generated types. Would call them something like Point and SearchResult but open to other names.

Does that direction sound good to you?