What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

When the Atlas Kubernetes Operator (v2.14.1) applies multiple IPAccessListEntry custom resources (generated CRD, v20250312) targeting the same Atlas project (same groupId) at approximately the same time — as happens naturally during a GitOps sync that provisions several access-list entries for a project in one pass — some entries intermittently fail with ATLAS_NETWORK_PERMISSION_ENTRY_NOT_FOUND shortly after creation, while sibling entries against the same project succeed in the same batch. The failing resource does not self-heal on later reconciles and remains stuck in an Error state indefinitely. The same entry type succeeds reliably when applied in isolation, which points to a race condition in how concurrent writes to a single project's shared access list are handled, either by the operator or by Atlas's own API.

What would you like to see happen?

Describe the desired outcome or enhancement.

The operator should avoid surfacing a terminal Error state from a 404 immediately following a create call under concurrent load. Ideally it would either: (1) serialize or queue reconciliation of IPAccessListEntry resources that share the same groupId, so concurrent writes to the same project's access list don't race each other; (2) retry the status-check call with backoff before marking the resource as failed, since this 404 pattern is consistent with an in-flight sibling write rather than an actual failure; or (3) periodically re-attempt reconciliation for resources already in this error state and self-heal automatically once the entry becomes visible in Atlas, rather than requiring the resource to be manually deleted and recreated.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

We are a platform team managing many Atlas projects and their IP access lists via GitOps (ArgoCD) at scale. Applying several IPAccessListEntry resources per project in a single sync wave is normal, expected usage, not an edge case. Requiring manual delete-and-recreate of individual stuck CRs to resolve this is not operationally feasible at our scale — it turns a routine provisioning operation into ongoing manual toil, and stuck resources can silently block downstream reconciliation (e.g. dependent resources or deletion protection/finalizers) until someone notices and intervenes.

What steps, if any, are you taking today to manage this problem?

Currently the only reliable workaround we've found is manually deleting and recreating the affected IPAccessListEntry custom resource, which triggers a clean create/status-check cycle. We are also considering building an automated remediation controller that detects resources stuck in this specific error state and forces a reconcile or delete/recreate automatically, but this is a workaround, not a fix, and adds operational complexity we'd rather not maintain long-term.