[E2E Test] ElastiService Should Handle Invalid CR Inputs Gracefully

[ramantehlan]

Expected Behaviour

The Elasti controller should never crash or panic due to invalid values in a custom resource. This test aims to ensure robustness by validating how the controller behaves when incorrect or unsupported values are set in an ElastiService spec.

The controller should log appropriate errors or ignore invalid specs, but should not break.

Here are a few invalid input cases we want to cover:

• Setting extremely large values (beyond int64) for fields like:

  • cooldownPeriod
  • minTargetReplicas

• Providing a scaleTargetRef:

  • With a resource kind that isn’t supported
  • That refers to a non-existent workload

• Specifying a service that doesn't exist in the cluster

• Providing a malformed trigger, such as:

  • Invalid serverAddress
  • Malformed query
  • Missing fields like threshold

Here’s the structure of the CRD for reference:

apiVersion: elasti.truefoundry.com/v1alpha1
kind: ElastiService
metadata:
  name: target-elastiservice
spec:
  cooldownPeriod: 30
  minTargetReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: deployments
    name: target-deployment
  service: target-deployment
  triggers:
    - metadata:
        query: round(sum(rate(envoy_http_downstream_rq_total{container="istio-proxy"}[1m])),0.001) or vector(0)
        serverAddress: http://prometheus-operated.monitoring.svc.cluster.local:9090
        threshold: "0.01"
      type: prometheus

Scenario

You don’t have to follow this rigidly—it’s just a starting point for planning:

1. Apply an ElastiService manifest with known invalid values.
2. Assert that the controller does not crash or exit.
3. Optionally, test additional controller behaviors like:
   • Attempting to scale manually
   • Simulating traffic to see if autoscaling still works for valid services

---

💡 E2E vs Unit Test?

Some validations (like type/format errors) might be better suited for unit tests.
Others—like missing services or invalid scaleTargetRef—must be tested in E2E, since they require cluster state awareness.