what‘s the behavior of consecutiveErrorLimit？I tested reach consecutiveErrorLimit will not degrade

[13567436138]

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 60s
    count: 5
    successCondition: result[0] >= 0.5
    failureLimit: 3
    consecutiveErrorLimit: 2
    provider:
      job:
        spec:
          backoffLimit: 1
          template:
            metadata:
              annotations:
                sidecar.istio.io/inject: “true”
            spec:
              containers:
              - name: test
                image: busybox
                command: [wget]
                args: ["http://192.168.229.134:30684/error"]
              restartPolicy: Never

what‘s the behavior of consecutiveErrorLimit？I tested reach consecutiveErrorLimit will not degrade

[jessesuen]

Errors are treated differently than Failures. Errors happen when the controller failed to perform the request (e.g. due to environmental issues such as network connectivity), whereas with a Failure, we were able to successfully performed the request, but the returned value evaluated as unsuccessful (e.g. the latency exceeded threshhold).

consecutiveErrorLimit is the maximum number of errors that can happen in succession before the metric is marked as an error. We decided to use a consecutive count instead of a total count, because unlike failures, errors tend to happen ephemerally and may recover on its own. For example, if there is a temporary DNS glitch at time A, but then recovers at time B, and then starts happening again at time C, you usually want the error count from time A to contribute to the error count at time C. You instead want to "reset" the count as soon as things start working again at time B.

Note that this is a limit, so to fail the metric, it will need to occur limit + 1 times.