Istio and Flux - observedGeneration

[hrvatskibogmars]

Hello,

I'm currently encountering a type mismatch error when using Istio + Flux and would appreciate any guidance or suggestions to resolve it. The issue arises with the status.observedGeneration field, which is expected to be an integer (int64), but it's being interpreted or provided as a string (string). Here's the specific error message I'm receiving:

Warning HealthCheckFailed 2m32s (x17 over 83m) kustomize-controller (combined from similar events): health check failed after 5m0.055393312s: timeout waiting for: [VirtualService/default/vs-front-imba status: 'Unknown': looking up status.observedGeneration from resource: .status.observedGeneration accessor error: 3 is of the type string, expected int64]

virtual-service.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-api-imba
  namespace: default
spec:
  gateways:
  - gw-global-lb-portal-imba
  hosts:
  -imba.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: api
        port:
          number: 80

[hrvatskibogmars]

There is a similar issue reported here
istio/istio#39605

[dan0sh]

Hi @stefanprodan,

is there a way to bypass this type mismatch using spec.healthCheckExprs? We are using a custom CRD where .status.observedGeneration is intentionally typed as string, which causes Flux's built-in assessor to fail with:

status: 'Unknown': .status.observedGeneration accessor error: 1 is of the type string, expected int64]

[matheuscscp]

Hmm, turns out we error out via .spec.healthCheckExprs too:

https://github.com/fluxcd/pkg/blob/1bfcca47168cb6d2d7dfdc5b35d8b379a773976d/runtime/cel/status_evaluator.go#L93-L96

This needs a fix

[matheuscscp]

Yep, I just reproduced with .status.ObservedGeneration: "1", the code above returns the following error:

.status.observedGeneration accessor error: 1 is of the type string, expected int64

[matheuscscp]

@dan0sh Which resource type has this issue for you?

[dan0sh]

Argo Rollouts, unfortunately, they have two open issues related to this:
argoproj/argo-rollouts#3402
argoproj/argo-rollouts#4672

[matheuscscp]

This can be fixed by specifying .spec.healthCheckExprs with expressions that correctly deal with the .status field of the resources in question starting with Flux 2.9 (end of 2026 Q2).