[bug]: GetObjectsAsync<T> return type is non-nullable but returns null for missing object IDs

[rob-wwnz]

Description

Summary

GetObjectsAsync<T> declares a non-nullable return type for retrieved objects, but the documented behaviour for missing object IDs returns null per item. Under C# Nullable Reference Types, this means consumers get no compile-time or type-level signal that a null check is required — it's a foot-gun for an unhandled NullReferenceException at runtime.

Package

• Package: Algolia.Search
• Version: 7.40.0 (current v7 client, generated from OpenAPI spec)
• Target framework: net10.0

Method signature in question

Task<GetObjectsResponse<T>> GetObjectsAsync<T>(
    GetObjectsParams getObjectsParams,
    RequestOptions options = null,
    CancellationToken cancellationToken = default
);

T is unannotated (non-nullable under NRT), implying every retrieved object is guaranteed non-null.

Documented behaviour

Per the current Get Objects documentation:

If an object ID isn't found in your index, the result is null for that object ID.

Reference: https://www.algolia.com/doc/libraries/sdk/methods/search/get-objects

Actual behaviour observed

When one or more requested object IDs don't exist in the index, the corresponding entries in GetObjectsResponse<T>.Results are null at runtime, despite T being declared non-nullable in the method signature.

Expected behaviour

One of:

1. Update the signature to reflect the documented nullability, e.g. Task<GetObjectsResponse<T?>>, so NRT-aware consumers get a compiler warning (CS8602/CS8600) if they dereference a result without checking.
2. If changing the public signature is an unwanted breaking change, document this explicitly in the XML doc comments for GetObjectsAsync so it's visible via IntelliSense at the call site, not just on the website docs.

Why this matters

The value of enabling Nullable Reference Types is trusting the compiler's nullability contract instead of defensively null-checking everything. A non-nullable generic return type that can silently contain nulls, with no compiler signal, undermines that guarantee and is easy to miss until it causes a production incident.

Repro steps

1. Call GetObjectsAsync<T> with a list of object IDs where at least one ID does not exist in the index.
2. Inspect the returned GetObjectsResponse<T>.Results.
3. Observe the entry for the missing ID is null, despite T being non-nullable per the method's declared signature.

Client

Search

Version

7.40.0

Relevant log output

[Fluf22]

@rob-wwnz thank you for your report, we are working on it