operator: set status for child objects if no parent objects exist

[AndrewChubatiuk]

Change should address comment #1181 (comment)

[cubic-dev-ai]

All reported issues were addressed across 15 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 15 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/controller/operator/factory/reconcile/status.go">

<violation number="1" location="internal/controller/operator/factory/reconcile/status.go:243">
P2: When a parent CR is deleted, its Applied condition can remain on the child because no parent reconcile releases it. This function aggregates that stale condition, so an unselected child remains operational or failed instead of becoming ignored; verify that no parents remain before retaining or aggregating persisted Applied conditions.</violation>
</file>

<sub>Requires human review: Auto-approval blocked because this review re-detected 2 unresolved issues already reported by Cubic.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

7 issues found across 21 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/controller/operator/controllers.go">

<violation number="1" location="internal/controller/operator/controllers.go:413">
P1: When cleanup for one scrape kind fails, `releaseScrapeChildStatuses` returns before releasing conditions from the remaining kinds. Since VMAgent/VMSingle finalizers are removed before this helper runs, aggregate the errors while attempting every kind so one transient failure does not leave stale child statuses permanently.</violation>
</file>

<file name="internal/controller/operator/vmservicescrape_controller.go">

<violation number="1" location="internal/controller/operator/vmservicescrape_controller.go:88">
P2: When parent discovery fails, this still recomputes the child status and can write `UpdateStatusIgnored` from empty conditions, falsely reporting that no parent selected the object. Distinguish parent-list failures from per-child reconciliation errors and skip aggregation when discovery is incomplete.</violation>
</file>

<file name="internal/controller/operator/vmstaticscrape_controller.go">

<violation number="1" location="internal/controller/operator/vmstaticscrape_controller.go:67">
P2: When either parent collector fails before discovering parents, this line still recomputes the child status from incomplete conditions. A transient VMAgent list failure can therefore mark a VMStaticScrape as `Ignored` even while a VMAgent exists; run the aggregate sync only after both collectors succeed.</violation>
</file>

<file name="internal/controller/operator/vmsingle_controller.go">

<violation number="1" location="internal/controller/operator/vmsingle_controller.go:107">
P2: When `releaseScrapeChildStatuses` fails, `OnVMSingleDelete` has already removed the VMSingle finalizer, so deletion completes without a retry and child scrape objects retain stale `vmsingleApplied` conditions. Release child statuses before calling `OnVMSingleDelete`, keeping the finalizer until cleanup succeeds.</violation>
</file>

<file name="internal/controller/operator/vmalertmanagerconfig_controller.go">

<violation number="1" location="internal/controller/operator/vmalertmanagerconfig_controller.go:141">
P2: When any parent reconcile fails, this condition discards a child-status synchronization error. Combine both errors (for example with `errors.Join`) so failed child status updates are reported and retried rather than being masked by the parent error.</violation>
</file>

<file name="internal/controller/operator/vmprobe_controller.go">

<violation number="1" location="internal/controller/operator/vmprobe_controller.go:88">
P2: When either parent collection fails, this line still recomputes the child from stale conditions. A transient parent-list failure can therefore write `UpdateStatusIgnored` even when parents exist; sync only after collection succeeds.</violation>
</file>

<file name="internal/controller/operator/vmalert_controller.go">

<violation number="1" location="internal/controller/operator/vmalert_controller.go:102">
P2: The child status release runs after OnVMAlertDelete has removed the VMAlert finalizer. If StatusForChildObjects fails here, the object is already gone and the next reconcile hits NotFound, so the parent condition on any still-attached VMRule is never released and stays stale. Run StatusForChildObjects before finalize.OnVMAlertDelete so a failure keeps the finalizer and lets the reconcile retry.</violation>
</file>

<sub>Tip: instead of fixing issues one by one fix them all with cubic
Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

2 issues found across 21 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/controller/operator/vmauth_controller.go">

<violation number="1" location="internal/controller/operator/vmauth_controller.go:100">
P2: If the VMAuth name or namespace contains a dot, this parentObject becomes `name.ns.vmauth` with more than three dot-separated parts and childConditionType() panics. On deletion the panic fires before finalize.OnVMAuthDelete, so the finalizer is never removed and the VMAuth remains stuck in terminating state while its VMUser status conditions are never released. Guard against non-three-part names before calling StatusForChildObjects.</violation>
</file>

<file name="internal/controller/operator/vmalert_controller.go">

<violation number="1" location="internal/controller/operator/vmalert_controller.go:99">
P2: When a parent CR name or namespace contains a dot, the `parentObject` string has more than 3 dot-separated segments, so `childConditionType` panics ("BUG: unexpected format...") before the finalizer is removed. A VMAlert named `my.alert` or a namespace like `prod.vm` is a valid object name, so the deletion reconcile panics, the finalizer is never removed, and the parent stays stuck in deletion forever. Derive the parent key in a way that cannot be confused by dots rather than splitting the concatenated string on dots.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 21 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/controller/operator/vmauth_controller.go">

<violation number="1" location="internal/controller/operator/vmauth_controller.go:101">
P3: On StatusForChildObjects error the branch returns without removing the VMAuth finalizer, so deletion stays pending until a retry succeeds; this mirrors the existing vmagent/vmsingle releaseScrapeChildStatuses pattern and self-heals on the retry. No change required.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

2 issues found across 21 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="internal/controller/operator/vmalertmanager_controller.go">

<violation number="1" location="internal/controller/operator/vmalertmanager_controller.go:103">
P1: When the VMAlertmanagerConfig controller or CRD is disabled, this call still lists VMAlertmanagerConfigs and returns a discovery error. The early return prevents `finalize.OnVMAlertManagerDelete`, leaving the VMAlertmanager finalizer and object stuck; skip this cleanup when VMAlertmanagerConfig is disabled, as config generation already does.</violation>
</file>

<file name="internal/controller/operator/controllers.go">

<violation number="1" location="internal/controller/operator/controllers.go:414">
P1: When any scrape CRD is disabled or absent, this call returns `NotFound`, so VMAgent/VMSingle deletion exits before `OnVMAgentDelete`/`OnVMSingleDelete` removes the finalizer. Skip unavailable scrape kinds or ignore their `NotFound` errors during cleanup.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 21 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 24 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 22 files (changes from recent commits).

<sub>Tip: instead of fixing issues one by one fix them all with cubic
Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[AndrewChubatiuk]

@cubic-ai-dev

[cubic-dev-ai]

@cubic-ai-dev

@AndrewChubatiuk I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 22 files

<sub>Heads up: you’re close to your included review allowance. Set a flex budget so reviews don’t pause.

Re-trigger cubic</sub>

[vrutkovs]

Needs if !instance.IsUnmanaged(nil) {

[AndrewChubatiuk]

isUnmanaged is for parent objects, not for child as in this case

[vrutkovs]

Needs if !instance.IsUnmanaged(nil) { section

[AndrewChubatiuk]

IsUnmanaged is to identify if parent object can manage exact child object, this is not applicable here