kubernetes-sigs / kubernetes-sigs/node-readiness-controller

processNodeAgainstAllRules can write an empty NodeEvaluation that fails CRD validation and drops FailedNodes updates

Open
#217 1 comment 0 reactions 1 assignee View on GitHub

@sahitya-chandra is already working on this.

Since May 6, 2026.

kind/bug
Dominant language
Go
Stars
164
Forks
75
Avg merge
8d 23h
Merged PRs (30d)
13

Description

What happens

On a failed evaluation (evaluateRuleForNode returns an error, e.g. a non-retryable taint patch failure), processNodeAgainstAllRules still appends a zero-value NodeEvaluation{} to the rule-status patch:

https://github.com/kubernetes-sigs/node-readiness-controller/blob/main/internal/controller/node_controller.go#L159-L206

Every required field on NodeEvaluation (nodeName, conditionResults, taintStatus, lastEvaluationTime) is omitempty, so the empty entry serializes to {} and the apiserver rejects the entire Status().Patch with a 422:

status.nodeEvaluations[0].conditionResults: Required value,
status.nodeEvaluations[0].lastEvaluationTime: Required value,
status.nodeEvaluations[0].nodeName: Required value,
status.nodeEvaluations[0].taintStatus: Required value

The patch is atomic, and the FailedNodes update (recorded via recordNodeFailure) is bundled into the same patch, so it is rejected too. Net effect: on a failed evaluation nothing is persisted to rule.status, and the only signal is a controller log line. Confirmed via envtest.

Expected

Skip the empty NodeEvaluation on the failure path and still persist the FailedNodes entry, so the failure is visible via kubectl get nodereadinessrule -o yaml.

Reproduce

Make a node's taint patch fail persistently with a non-conflict error (e.g. RBAC-deny the nodes patch) so evaluateRuleForNode returns an error: the controller logs the 422 above and failedNodes never appears for that node.

/kind bug

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.