AbortOnFail has me flummoxed

Hey k6 crew. I have a question about why my abortOnFail option is not working for me.

I have 2 scenarios which I think are references by the error rate threshold/check

  'http_req_failed{scenario:browse_peak}': [{ threshold: 'rate < 1.0', abortOnFail: true, delayAbortEval: '30s' }],
        'http_req_failed{scenario:browse_gate_rush}': [{ threshold: 'rate < 1.0', abortOnFail: true, delayAbortEval: '30s' }],
    },

I have a test which throws a ton of requests timeouts on a purposely low bandwidth client connection to my test environment. the resulting output looks like this… why wouldn’t 9% http_req_failed not trigger the check to terminate the test?

     █ guest

       ✗ status is 200
        ↳  96% — ✓ 4300 / ✗ 176

     █ browse

       ✗ status is 200
        ↳  95% — ✓ 4281 / ✗ 198

     █ options

       ✗ status is 200
        ↳  96% — ✓ 4283 / ✗ 177

     █ browse_guest

       ✗ status is 200
        ↳  99% — ✓ 4137 / ✗ 14

     checks................................: 96.78% ✓ 17001     ✗ 565   
     data_received.........................: 117 MB 184 kB/s
     data_sent.............................: 18 MB  28 kB/s
     dropped_iterations....................: 1229   1.937985/s
     group_duration........................: avg=3.26s       min=16.53ms med=443.48ms max=1m0s      p(75)=1.45s    p(99)=1m0s       count=17566
     http_req_blocked......................: avg=1.41s       min=0s      med=5µs      max=29.98s    p(75)=409.93ms p(99)=26.11s     count=35461
     http_req_connecting...................: avg=1.09s       min=0s      med=0s       max=29.98s    p(75)=409.86ms p(99)=26.11s     count=35461
     http_req_duration.....................: avg=2.53s       min=0s      med=395.91ms max=1m0s      p(75)=1.37s    p(99)=47.55s     count=35461
       { expected_response:true }..........: avg=1.44s       min=76.15ms med=418.65ms max=59.15s    p(75)=1.31s    p(99)=14.65s     count=31965
     ✗ { test_type:browse_guest_peak }.....: avg=1.79s       min=0s      med=308.17ms max=1m0s      p(75)=1.22s    p(99)=30.48s     count=12014
     ✗ { test_type:browse_peak }...........: avg=2.96s       min=0s      med=477.27ms max=1m0s      p(75)=1.52s    p(99)=1m0s       count=7806 
     ✗ { test_type:concepts_guest_peak }...: avg=2.83s       min=0s      med=370.08ms max=1m0s      p(75)=1.32s    p(99)=1m0s       count=7824 
     ✗ { test_type:concepts_peak }.........: avg=2.94s       min=0s      med=463.07ms max=1m0s      p(75)=1.45s    p(99)=1m0s       count=7817 
     http_req_failed.......................: 9.85%  ✓ 3496      ✗ 31965 
     http_req_receiving....................: avg=174.94ms    min=0s      med=73µs     max=52.31s    p(75)=244µs    p(99)=3.87s      count=35461
     http_req_sending......................: avg=39.67µs     min=0s      med=29µs     max=2.59ms    p(75)=51µs     p(99)=155µs      count=35461
     http_req_tls_handshaking..............: avg=0s          min=0s      med=0s       max=0s        p(75)=0s       p(99)=0s         count=35461
     http_req_waiting......................: avg=2.36s       min=0s      med=388.1ms  max=1m0s      p(75)=1.21s    p(99)=47.17s     count=35461
     http_reqs.............................: 35461  55.917717/s
     iteration_duration....................: avg=12.48s      min=13.09ms med=5.46s    max=1m29s     p(75)=17.4s    p(99)=1m2s       count=20392
     iterations............................: 20392  32.155723/s
     transaction_time......................: avg=2728.538544 min=0       med=404.536  max=60009.313 p(75)=1355.093 p(99)=60001.3871 count=17566
     vus...................................: 1429   min=200     max=1429
     vus_max...............................: 1429   min=200     max=1429

Hi @PlayStay,

rate<1.0 means the rate needs to be under 1.0 so that the threshold isn’t breached and you won’t be aborted.

rate also goes from 0 (0%)to 1 (100%) so I guess in your case you want rate>0 or rate>0.01

Humble pie. got it. rate % is represented not by 1-100 but it’s decimal notation… thanks again.