Ability to display intermediate result while the test is running

[sniku]

This is a suggestion for the k6 process to listen to user input and react to commands while the test is running.

Feature Description

Specifically, I would like to be able to press R and to get intermediate results while my test is running. This is especially useful for long-running soak tests, that can take several hours to complete.

Currently, it's possible to get intermediate results by running a k6 stats command in another terminal window. This is however not ideal because the format is not human readable.

I suggest the intermediate result to have the same format as the regular end-of-test output k6 normally generates.

[na--]

Now that we have #1768, this issue should be relatively easy to implement. Though we might need to refactor the js.Runner a bit, if we want to be a bit more efficient and not spawn a VU every time we call handleSummary(). On the other hand, that would require a bit more locking so that if the user presses R multiple times in a rapid succession, we don't try to run handleSummary() more than once concurrently in the same runtime... 🤷‍♂️

Also, a keyboard letter like R might not be the best UI for this, a signal like Ctrl+Z (SIGTSTP) might be better? Or maybe not, considering its current use to move the process to the background... 😞

[na--]

As has become apparent in the course of #1849, this feature has a lot of hidden complexity and deserves a lot of consideration before we implement it. Specifically, we either have to accept a poor UX, or we have to deal with a lot of terminal strangeness... 😞

[imiric]

I don't see why we can't compromise and allow this to work with Enter instead of R. It avoids the mess of switching terminal modes and from my tests on top of a previous iteration of #1849 works quite well. Enter seems like a sensible binding for this type of output, and we won't have to implement some complex key listening functionality, which we arguably don't need.

[sniku]

My requirement of listening to R input was quite arbitrary. If listening to Enter removes complexities from this task, then I think we should change the requirement.

[na--]

Then doesn't it become too easy enough to trigger this accidentally? And very important that you don't accidentally pipe something to k6's stdin... Binding Enter would also preclude us from doing pretty much anything else with user interaction, i.e. we'd have to make a breaking change if we ever want more similar features in k6.

Mind you, I am not against this, I just want us to spend a bit more time thinking about it before we try again... 😅 It's not a very important feature, so I think we can let this lie for a while before we try again.

[na--]

There was an attempt to implement this issue (#1849), however, as it's obvious by the comments in the PR, there were some unexpectedly tricky issues around it (mostly in how the mid-test handleSummary() is invoked). I'd go as far as saying that listening for a key stroke is probably a very bad way to go about this issue, maybe exposing a REST API call or listening to signals would work better if we ever want to implement this in the future. For now, I'll keep this issue open, but it definitely still seems like a very low prio one.