{
  "topic": "errors.DELETE_NOT_CONVERGED",
  "path": [
    "errors",
    "DELETE_NOT_CONVERGED"
  ],
  "title": "DELETE_NOT_CONVERGED — a batched delete never ran out of matching entities",
  "synopsis": "`DELETE /entity/{entityName}/{modelVersion}` with `transactionSize` set (and no `pointInTime`) deletes in batches, re-selecting the matching entities before each batch. It finishes when a selection pass finds nothing left. If entities matching the condition are created at least as fast as they are removed, that pass never comes up empty, so the delete is capped at a fixed number of batches and fails with this code instead of running indefinitely.",
  "body": "# errors.DELETE_NOT_CONVERGED\n\n## NAME\n\nDELETE_NOT_CONVERGED — a batched delete kept finding new matching entities and was stopped before it finished.\n\n## SYNOPSIS\n\nHTTP: `409` `Conflict`. Retryable: `yes`.\n\n## DESCRIPTION\n\n`DELETE /entity/{entityName}/{modelVersion}` with `transactionSize` set (and no `pointInTime`) deletes in batches, re-selecting the matching entities before each batch. It finishes when a selection pass finds nothing left. If entities matching the condition are created at least as fast as they are removed, that pass never comes up empty, so the delete is capped at a fixed number of batches and fails with this code instead of running indefinitely.\n\nBatches that committed before the failure are durable — the matching entities are partially deleted. The request fails rather than returning counts, because those counts would describe only the part of the work that fit inside the cap, not the delete that was asked for.\n\nDo one of:\n\n- stop the writers that keep creating matching entities, then retry;\n- narrow the condition so the matching set is one the delete can drain;\n- retry as-is if the concurrent writes were a transient burst.\n\nAn unbatched delete (`transactionSize` absent) and a `pointInTime`-pinned delete both resolve their target set once and cannot raise this.\n\nNot to be confused with `CONFLICT`, which is a single entity losing an optimistic-concurrency race; the remedy there is to re-read that entity and replay the write.\n\n## SEE ALSO\n\n- errors\n- errors.CONFLICT\n",
  "sections": [
    {
      "name": "NAME",
      "body": "DELETE_NOT_CONVERGED — a batched delete kept finding new matching entities and was stopped before it finished."
    },
    {
      "name": "SYNOPSIS",
      "body": "HTTP: `409` `Conflict`. Retryable: `yes`."
    },
    {
      "name": "DESCRIPTION",
      "body": "`DELETE /entity/{entityName}/{modelVersion}` with `transactionSize` set (and no `pointInTime`) deletes in batches, re-selecting the matching entities before each batch. It finishes when a selection pass finds nothing left. If entities matching the condition are created at least as fast as they are removed, that pass never comes up empty, so the delete is capped at a fixed number of batches and fails with this code instead of running indefinitely.\n\nBatches that committed before the failure are durable — the matching entities are partially deleted. The request fails rather than returning counts, because those counts would describe only the part of the work that fit inside the cap, not the delete that was asked for.\n\nDo one of:\n\n- stop the writers that keep creating matching entities, then retry;\n- narrow the condition so the matching set is one the delete can drain;\n- retry as-is if the concurrent writes were a transient burst.\n\nAn unbatched delete (`transactionSize` absent) and a `pointInTime`-pinned delete both resolve their target set once and cannot raise this.\n\nNot to be confused with `CONFLICT`, which is a single entity losing an optimistic-concurrency race; the remedy there is to re-read that entity and replay the write."
    },
    {
      "name": "SEE ALSO",
      "body": "- errors\n- errors.CONFLICT"
    }
  ],
  "see_also": [
    "errors",
    "errors.CONFLICT"
  ],
  "stability": "stable",
  "actions": []
}