Partial indexing after retry with waitForTask – distinct deduplication shows duplicate

Short answer

No — a retried write with the same objectID cannot create a true duplicate in the index, and distinct cannot turn one stored object into two results. What you can observe after a timeout-and-retry is a transiently inconsistent read (stale replica data or a not‑yet‑propagated write), which can look like deduplication misbehaving without any duplicate ever existing.

Separating confirmed behavior from the uncertain part

Well‑established behavior

• Upsert semantics: Algolia writes are keyed by objectID. A second saveObject/partialUpdate with the same objectID replaces the existing record. The index holds at most one object per objectID, regardless of how many times the write is submitted.
• distinct is query‑time only: it groups or filters search results by the configured attribute. It plays no role in how objects are written or stored, so it cannot "interpret a partially indexed record as a duplicate" at write time.
• waitForTask scope: it makes the API hold the HTTP response until the indexing task is processed, rather than returning immediately with a taskID. It is a stronger confirmation than the default, but it is a per‑request wait on task completion — not a distributed guarantee that every replica in every zone has already served the new state to all subsequent queries.

The genuinely uncertain part

Whether a retry can ever observe a "partially indexed" object is not publicly documented in a way that supports a universal guarantee. Indexing is applied per object, so a half‑written object is not a realistic model; the realistic risk is propagation lag: the first task completed on the primary, your client timed out anyway, the retry succeeded quickly (because the upsert is idempotent in effect), and a subsequent search hit a replica that hadn't caught up. That produces confusing query results, not duplicate objects. Treat any stronger claim either way as unverified.

What would actually confirm or rule out a duplicate

1. Capture the taskID from both the original attempt (if any response arrived) and the retry. Poll the task status endpoint until each reports published/done or failed. Two completed tasks for the same objectID is normal and harmless.
2. Retrieve the object directly by objectID (a get‑object call, not a search). There will be exactly one record. If get‑object shows one record but search shows two rows, the cause is query‑time grouping (distinct attribute configuration) or replica lag — not write duplication.
3. Re‑run the same search a few seconds later. If the "duplicate" disappears, you observed propagation lag, confirming the index itself was never wrong.

Practical safeguards for the retry path

• Make retries idempotent by always reusing the same objectID (you already get this from upsert semantics).
• Prefer polling the returned taskID after a timeout instead of blindly resubmitting; if the original task completed, the retry is unnecessary.
• If you see apparent duplicates, check your distinct and attributeForDistinct settings first — misconfigured grouping is a far more common cause than indexing races.

One detail that would sharpen this diagnosis: whether the duplicate appears in search results or in a direct browse/get of the index. If it's search‑only, the explanation above (distinct config or replica lag) covers it; if a browse genuinely shows two records with the same objectID, that would contradict documented upsert behavior and should go to Algolia support with the task IDs.