Partial indexing after retry with waitForTask – distinct deduplication shows duplicate

The goal is to understand whether Algolia’s waitForTask parameter guarantees that an object is fully indexed before the request returns success, especially when a network timeout triggers a retry. If a retry occurs after a timeout, there is uncertainty about whether the second request could encounter a partially indexed record that the distinct deduplication setting might interpret as a duplicate, even though the underlying index has not yet stored a second object.

Constraints include the upsert semantics of objectID, the fact that distinct only affects query results and not index creation, and the community‑noted unresolved behavior regarding waitForTask and retry safety. No specific error string is quoted from sources.

Does waitForTask ensure complete indexing before returning a successful response? If a timeout occurs and the request is retried, could the retry see a partially indexed state that leads distinct to treat it as a duplicate? What observable behavior would confirm whether a partially indexed state can be mistaken for a duplicate under these conditions?