You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because the request timeout doesn't understand stringy durations, "2s" would be converted to 2 (because JavaScript 🤦♂️ ), so k6 would understand it as "2 milliseconds". So it's going to start to make a ton of requests instead of just 3...
However this script also doesn't work like how you'd expect either:
k6 runs, doesn't abort with a configuration error or something like that... but it interprets the 5000 value for duration as 5000 nanoseconds, i.e. 0.005 milliseconds, so it just immediately aborts... 🤦♂️ This is just a consequence of the way we've wrapped Go's time.Duration (which is nanosecond-based) in our types.Duration custom type (that parses things like "2s"). Only, when it doesn't get a string, it falls back to the nanosecond code...
So, I think we should unify and make everything saner... To do that with minimal breaking changes, I propose that we:
use the same duration type (types.Duration / types.NullDuration?) everywhere we accept user-specified duration
modify it so it either accepts valid string durations, or integer durations in milliseconds, everything else should be an error
So, the only breaking change is that users won't be able to specify the global options in nanoseconds, which won't be a big loss and I hope nobody has done...
The text was updated successfully, but these errors were encountered:
The thresholds is another place in k6 where we have configuration of time duration values. Thankfully, that's also in milliseconds, but there's currently no way to use string-y units like 1.5s... This is a lower-priority item to fix, since we have to synchronize with the cloud execution as well, but it doesn't make sense not to support it eventually. Of course, after we make the threshold parsing sane (#961).
ws.SetTimeout() and ws.SetInterval() are also places where we accept only millisecond-based duration values. And we recently found a problem with them accepting ints - if a user passes a float value, goja transforms it to 0 (#1608)... Even if that gets fixed, it's probably better for us, when we unify everything, to change all places to accept either a stringy duration (eg. 30s, 1.5m, 2h30m1s, etc.) , or a float millisecond value.
This overhaul is also necessary for timeUnit and duration and any other such properties in the new scenarios configuration, since they also accept integer nanosecond values 😭
This seemingly normal script won't work as most people expect:
Because the request timeout doesn't understand stringy durations,
"2s"
would be converted to2
(because JavaScript 🤦♂️ ), so k6 would understand it as "2 milliseconds". So it's going to start to make a ton of requests instead of just 3...However this script also doesn't work like how you'd expect either:
k6 runs, doesn't abort with a configuration error or something like that... but it interprets the
5000
value forduration
as 5000 nanoseconds, i.e. 0.005 milliseconds, so it just immediately aborts... 🤦♂️ This is just a consequence of the way we've wrapped Go'stime.Duration
(which is nanosecond-based) in ourtypes.Duration
custom type (that parses things like"2s"
). Only, when it doesn't get a string, it falls back to the nanosecond code...So, I think we should unify and make everything saner... To do that with minimal breaking changes, I propose that we:
types.Duration
/types.NullDuration
?) everywhere we accept user-specified durationSo, the only breaking change is that users won't be able to specify the global options in nanoseconds, which won't be a big loss and I hope nobody has done...
The text was updated successfully, but these errors were encountered: