StatusNotWritten

Docs version v1 (main) · Nauthera is pre-1.0, in a design-partner program

An outcome could not be written to the resource's status; a Warning event on the resource, with no condition of its own.

#Meaning

The operator reached an outcome and the API server refused the status update. The event carries the outcome's reason and message and the API server's error. Causes: the resource changed between read and write (a conflict), the operator lacks permission on the kind's status, the API server was unavailable, or the installed resource definition is older than the operator and refuses a field. The reconcile is retried with backoff.

#Impact

The resource shows a stale condition, so the application team reads an old state. What the operator did on the server (registered, refused, removed) still happened. One event followed by a fresh condition needs nothing; repeated events leave every reader of status misled.

#Diagnosis

1. kubectl get events -A --field-selector reason=StatusNotWritten for the API server's error.
2. increase(nauthera_operator_reconciles_total{reason="StatusNotWritten"}[1h]) by kind.
3. kubectl auth can-i update oidcclients/status --as=system:serviceaccount:<release-ns>:<release>-operator -A.
4. kubectl get crd oidcclients.nauthera.io -o yaml against the chart version installed.

#Mitigation

• A conflict resolves on retry. Persistent ones point to another controller writing status.
• Missing permission: set operator.rbac.create: true or restore the ClusterRole's status rules.
• An old definition: keep operator.crds.install: true so helm upgrade applies it.

#Escalation

Escalate to the platform team when events repeat for more than a few minutes. If permission and definitions are current and the API server still refuses the field, open an issue with the event, both versions and kubectl get crd <crd> -o yaml.

Operator failure reasons · Generated from operator/internal/runbook/conditions.yaml in nauthera-server.