Status condition not persisted when OIDCConfigHash unchanged after transient error

[ChrisJBurns]

Summary

In all three workload controllers (MCPServer, VirtualMCPServer, MCPRemoteProxy), handleOIDCConfig sets the OIDCConfigRefValidated condition to True in memory after validation passes, but only calls r.Status().Update() inside the if hash changed block. If the condition was previously False (e.g., after a transient error where the MCPOIDCConfig was temporarily unavailable) and is now True, but the config hash hasn't changed, the condition update is never persisted.

Scenario

1. MCPOIDCConfig exists and is valid → hash stored, condition=True
2. MCPOIDCConfig temporarily deleted → condition set to False, phase=Failed
3. MCPOIDCConfig re-created with same content (same hash) → condition set to True in memory but Status().Update() skipped because hash is unchanged

The condition eventually self-heals on the next reconcile that changes hash or on a full resync, but there's a window where the status is stale.

Affected controllers

• MCPServerReconciler.handleOIDCConfig (mcpserver_controller.go)
• VirtualMCPServerReconciler.handleOIDCConfig (virtualmcpserver_controller.go)
• MCPRemoteProxyReconciler.handleOIDCConfig (mcpremoteproxy_controller.go)

Proposed fix

After setting the valid condition and checking the hash, add an unconditional status update if the condition changed (similar to how MCPOIDCConfigReconciler.Reconcile handles conditionChanged). Alternatively, always persist status when the condition transitions from False→True regardless of hash state.

Severity

Low — the condition self-heals on the next reconcile cycle that triggers a status write. No functional impact on workload deployment since the reconcile loop continues past this point.

[ChrisJBurns]

@claude Is #4509 the same as this?

[claude]

Claude finished @ChrisJBurns's task in 1m 45s —— View job

---

Analysis: Is PR #4509 the same as this issue?

I reviewed the relevant handleOIDCConfig implementations in the current codebase to answer this.

The bug from this issue (#4511) is still present in main — PR #4509 has not been merged yet (the latest merged PR is #4501). So there's no overlap from a "already fixed" perspective.

However, whether #4509 addresses the same root cause depends on what it changes. I was unable to fetch the PR directly (no gh/curl access approved), but I can describe precisely what this issue requires and what to look for in #4509:

What issue #4511 describes

In all three workload controllers, after OIDC validation succeeds, the condition is set in memory but Status().Update() is only called inside the if hash changed block. Example from mcpserver_controller.go:2094-2111:

// Set valid condition — in memory only
setOIDCConfigRefCondition(m, metav1.ConditionTrue, ...)

// Status().Update() ONLY called here — misses condition-only changes
if m.Status.OIDCConfigHash != oidcConfig.Status.ConfigHash {
    m.Status.OIDCConfigHash = oidcConfig.Status.ConfigHash
    if err := r.Status().Update(ctx, m); err != nil { ... }
}

If the hash is unchanged (same config re-created after deletion), the True condition is never persisted.

How to tell if #4509 is the same

PR #4509 would address the same issue if it moves Status().Update() outside the hash-check block (unconditional persist when condition changed), or adds a separate condition-change check. It would be a different issue if it fixes something else (e.g., a different field, different controller, different race condition).

My recommendation: Check #4509's diff against handleOIDCConfig in mcpserver_controller.go, virtualmcpserver_controller.go, and mcpremoteproxy_controller.go. If it restructures the Status().Update() call to be unconditional (or condition-aware), it's fixing the same bug. If not, this issue is still open and separate.