What happens when you delete a nonexistent point or upsert an ID that already exists?

Deleting a point that is already absent is normally treated as an idempotent operation rather than a 'not found' application error. This is useful for retryable cleanup workflows because repeating a delete does not require a prior existence check.

When an upsert uses an existing point ID, the operation targets that existing point and applies the upsert semantics rather than creating a second point with the same ID. The ID therefore acts as the stable key for point writes.

The practical advantage is simpler distributed pipelines: retries and duplicate events can be handled without a read-before-write or read-before-delete sequence. However, idempotency of the Qdrant operation does not mean your entire workflow is idempotent if external side effects happen before or after the database call.

A common mistake is assuming every write should be preceded by a lookup. That adds latency and creates a race window. Prefer the atomic point operation and design the surrounding workflow for retries.