chore: move Spec.ParsingError to Status.ParsingSpecError

[AndrewChubatiuk]

fixes #2113

implemented custom UnmarshalJSON for CR instead of its spec, which allowed to move parsing spec error from Spec to Status. With custom spec unmarshalling spec error is hidden from structs, that may embed it: VMDistributedSpec embeds VMClusterSpec and VMAuthSpec

---

Summary by cubic

Moves spec parse error handling from Spec to Status across all CRDs by adding root-level UnmarshalJSON that records errors in Status.ParsingSpecError. This makes parse errors visible in Status, prevents leaks from embedded specs, and stops infinite reconciles (fixes #2113).

• Refactors

  • Replaced *.Spec.ParsingError with *.Status.ParsingSpecError across v1, v1alpha1, and v1beta1, including scrape CRs via ScrapeObjectStatus.
  • Implemented root-level UnmarshalJSON for each CR to parse spec and capture errors in Status; removed spec-level fields/unmarshalers.
  • Updated controllers, admission webhooks, IsUnmanaged checks, and tests to use Status.ParsingSpecError.

• Bug Fixes

  • Parse errors now surface in Status and short-circuit reconcile/webhook validation; nested route/spec errors in VMAlertmanagerConfig and embedded specs no longer leak or loop.
  • Changelog: VMDistributed/VMClusterSpec parse errors are now shown instead of being swallowed, resolving infinite reconciles (bug: vmdistributed creates a lot of ReconcileEvents #2113).

^{Written for commit ef421cb. Summary will update on new commits. Review in cubic}

[cubic-dev-ai]

21 issues found across 71 files

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="api/operator/v1/vmanomaly_types.go">

<violation number="1" location="api/operator/v1/vmanomaly_types.go:333">
P1: The `UnmarshalTypeError` field check is too narrow and misses nested `spec.*` parse errors, so many spec parsing failures are no longer captured in `Status.ParsingSpecError`.</violation>
</file>

<file name="api/operator/v1beta1/vmcluster_types.go">

<violation number="1" location="api/operator/v1beta1/vmcluster_types.go:218">
P1: Spec parse errors in nested spec fields are missed because the field check only matches `"spec"` exactly.</violation>
</file>

<file name="api/operator/v1beta1/vmnodescrape_types.go">

<violation number="1" location="api/operator/v1beta1/vmnodescrape_types.go:92">
P1: Nested spec type errors are no longer captured into `Status.ParsingSpecError` because the check only matches `Field == "spec"`. This can cause CR unmarshal to fail for invalid `spec.*` fields instead of reporting the parsing error in status.</violation>
</file>

<file name="api/operator/v1beta1/vmpodscrape_types.go">

<violation number="1" location="api/operator/v1beta1/vmpodscrape_types.go:157">
P2: `UnmarshalTypeError.Field` matching is too strict; nested spec type errors (`spec.<field>`) bypass `ParsingSpecError` and return hard unmarshal errors.</violation>
</file>

<file name="api/operator/v1/vlsingle_types.go">

<violation number="1" location="api/operator/v1/vlsingle_types.go:168">
P2: Nested spec type errors are missed because the check only matches `unmarshalErr.Field == "spec"`.</violation>
</file>

<file name="api/operator/v1beta1/vmalert_types.go">

<violation number="1" location="api/operator/v1beta1/vmalert_types.go:184">
P1: Spec parse error handling is too narrow: it only catches `unmarshalErr.Field == "spec"`, so nested spec type errors (for example `spec.someField`) return hard decode errors instead of being recorded in `Status.ParsingSpecError`.</violation>
</file>

<file name="api/operator/v1beta1/vmuser_types.go">

<violation number="1" location="api/operator/v1beta1/vmuser_types.go:345">
P1: Spec parse errors in nested fields are not captured because the check only matches `Field == "spec"`.</violation>
</file>

<file name="api/operator/v1beta1/vmsingle_types.go">

<violation number="1" location="api/operator/v1beta1/vmsingle_types.go:216">
P1: The `UnmarshalTypeError` field check is too strict (`== "spec"`) and misses nested spec decode errors (e.g. `spec.port`), so many spec parsing failures now return hard errors instead of populating `status.ParsingSpecError`.</violation>
</file>

<file name="api/operator/v1beta1/vmalertmanager_types.go">

<violation number="1" location="api/operator/v1beta1/vmalertmanager_types.go:290">
P1: Nested spec unmarshal type errors are not handled because the field check only matches `"spec"` exactly.</violation>
</file>

<file name="api/operator/v1alpha1/vmdistributed_types.go">

<violation number="1" location="api/operator/v1alpha1/vmdistributed_types.go:435">
P1: The `UnmarshalTypeError` check is too strict: nested spec parse errors use field paths like `spec.*`, so they bypass this branch and return an error instead of being recorded as `ParsingSpecError`.</violation>
</file>

<file name="api/operator/v1beta1/vmauth_types.go">

<violation number="1" location="api/operator/v1beta1/vmauth_types.go:583">
P2: The new spec parse-error handling only matches `Field == "spec"`, so nested spec field type errors are missed and returned as hard unmarshal failures.</violation>
</file>

<file name="api/operator/v1beta1/vmagent_types.go">

<violation number="1" location="api/operator/v1beta1/vmagent_types.go:276">
P1: Nested spec unmarshal errors are not captured because the field check only matches `"spec"` exactly.</violation>
</file>

<file name="api/operator/v1/vtcluster_types.go">

<violation number="1" location="api/operator/v1/vtcluster_types.go:586">
P2: Spec parsing errors in nested fields are missed because the check only matches `Field == "spec"`.</violation>
</file>

<file name="api/operator/v1beta1/vmservicescrape_types.go">

<violation number="1" location="api/operator/v1beta1/vmservicescrape_types.go:179">
P2: Spec parse errors in nested fields are missed because the check only matches `Field == "spec"` instead of the full `spec.*` path.</violation>
</file>

<file name="api/operator/v1beta1/vlogs_types.go">

<violation number="1" location="api/operator/v1beta1/vlogs_types.go:180">
P1: Nested spec type errors are no longer captured because the check only matches `unmarshalErr.Field == "spec"`.</violation>
</file>

<file name="api/operator/v1beta1/vmprobe_types.go">

<violation number="1" location="api/operator/v1beta1/vmprobe_types.go:172">
P2: Nested spec type errors are not captured because the field check only matches `"spec"` exactly.</violation>
</file>

<file name="api/operator/v1/vtsingle_types.go">

<violation number="1" location="api/operator/v1/vtsingle_types.go:158">
P1: Nested spec type errors are not captured because the field check only matches `"spec"`; errors like `"spec.num"` will return hard decode errors instead of setting `Status.ParsingSpecError`.</violation>
</file>

<file name="api/operator/v1beta1/vmscrapeconfig_types.go">

<violation number="1" location="api/operator/v1beta1/vmscrapeconfig_types.go:658">
P1: Spec parse errors for nested fields are no longer captured because the check only matches `Field == "spec"`; nested errors like `spec.<field>` now return a hard unmarshal error.</violation>
</file>

<file name="api/operator/v1beta1/vmstaticscrape_types.go">

<violation number="1" location="api/operator/v1beta1/vmstaticscrape_types.go:98">
P2: The spec parse-error handling is too narrow: it only matches `unmarshalErr.Field == "spec"`, so nested spec type errors bypass `Status.ParsingSpecError` and return a hard unmarshal error.</violation>
</file>

<file name="api/operator/v1/vlcluster_types.go">

<violation number="1" location="api/operator/v1/vlcluster_types.go:676">
P1: The `spec` parse-error guard is too strict (`== "spec"`) and misses nested spec unmarshal failures, causing them to return hard errors instead of being captured in `Status.ParsingSpecError`.</violation>
</file>

<file name="api/operator/v1/vlagent_types.go">

<violation number="1" location="api/operator/v1/vlagent_types.go:354">
P1: Nested spec parse errors are not handled because the check only matches `Field == "spec"`.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}